2010-03-06 33 views
6

Tìm kiếm các đề xuất/phương pháp hay nhất về quản lý mã lỗi và tin nhắn trong ứng dụng nhiều tầng. Cụ thể những điều như:Phương pháp tiếp cận cho mã lỗi/quản lý tin nhắn trong .NET

  1. Mã lỗi phải được xác định ở đâu? Enum? Lớp học?
  2. Thông báo lỗi hoặc các chi tiết khác liên quan đến mã lỗi như thế nào? tệp tài nguyên? thuộc tính trên giá trị enum, v.v ...?
  3. Nếu bạn có một ứng dụng nhiều tầng bao gồm DAL, BLL, giao diện người dùng và các dự án chung, chẳng hạn, có một danh sách khổng lồ các mã cho tất cả các tầng hoặc mã có thể mở rộng theo dự án/tầng không?

Cập nhật: quan trọng cần đề cập đến mà tôi không thể chỉ dựa vào Exceptions và các loại tùy chỉnh ngoại lệ để báo cáo lỗi, như một số khách hàng cho ứng dụng này sẽ được thông qua các dịch vụ web (SOAP & REST) ​​

Bất kỳ đề nghị chào đón!

Trả lời

2

Tôi nghĩ rằng Nó là tốt hơn để tạo ra một dự án chung (hoặc dự án ApplicationFramework) và đặt Exceptions của bạn và Object Common trên đó.

Nó luôn luôn là một ý tưởng tốt để có một ApplicationFramework chứa Base Class cho lớp của bạn (đặc biệt trong giao diện người dùng - PageBase - MasterBase- ModuleBase và vv)

Và như rõ ràng của nó bạn cần phải đặt lớp học của bạn và Enums trong dự án BLL của bạn.

Lưu ý rằng 3 tầng không có nghĩa là 3 Dự án. Bạn có thể có 5 dự án trong BLL của bạn.

Cuối cùng đừng quên sử dụng ELMAH hoặc bất kỳ công cụ tương tự nào khác.

6

Mã lỗi là skool cũ, bạn cần chúng trở lại trong những ngày cũ của chương trình COM và C, môi trường không hỗ trợ ngoại lệ. Ngày nay, bạn sử dụng các ngoại lệ để thông báo mã máy khách hoặc người dùng về các vấn đề. Ngoại lệ trong .NET là tự mô tả, chúng có kiểu, thông báo và chẩn đoán.

Bạn cần phải phân biệt hai loại ngoại lệ, những loại được khôi phục hợp lý và những trường hợp bạn không biết chính xác điều gì đã xảy ra sai hoặc cách bạn khôi phục chúng. Loại thứ hai là phổ biến nhất, bạn sẽ cần một con người để có hành động khắc phục. Sử dụng một trong các kiểu ngoại lệ .NET tích hợp sẵn để tăng chúng. IllegalOperationException, FormatException, ArgumentException là các lựa chọn phổ biến. Nếu nó là back-end mà làm tăng một ngoại lệ như vậy thì bạn chỉ muốn vượt qua nó mà không cần thay đổi. Bạn thường cần một khối cuối cùng để đảm bảo trạng thái bên trong của bạn nhất quán, đôi khi một khối catch chứa một cú ném đơn giản để phục hồi trạng thái.

Bất kỳ điều gì bạn cho là có thể phục hồi đều phải được nâng lên với loại ngoại lệ mà bạn tự khai báo, bắt nguồn từ lớp Ngoại lệ. Điều đó mang lại cho mã ngược dòng một cơ hội để viết một mệnh đề bắt và làm điều gì đó có ý nghĩa. Bạn sẽ cần tạo một Thông báo mô tả vấn đề, trong trường hợp mã lên dòng không thực sự xử lý nó, văn bản của thư cần phải được truy lục từ chuỗi ký tự cứng hoặc tài nguyên nếu bạn hỗ trợ nội địa hóa.

+0

Cảm ơn bạn đã nhập. Tôi đã cập nhật câu hỏi ban đầu để đề cập đến rằng tôi không thể chỉ dựa vào ngoại lệ vì một số khách hàng sẽ được thông qua dịch vụ web và đặc biệt là các dịch vụ web REST không có khái niệm về "loại ngoại lệ". Nhìn vào một số API của internet (Facebook, Flickr, v.v.) khiến tôi tin rằng mã lỗi trong cách sử dụng này là cách để đi. – WayneC

+0

@WayneC: Các dịch vụ web SOAP có quyền truy cập vào lỗi SOAP. Quá tệ khi REST yêu cầu bạn hoàn nguyên về đầu những năm 90. –

+0

@John: Bạn có nói rằng REST API là "đầu những năm 90" không? Ai đó tốt hơn nên nói với Facebook, Flickr, Netflix, Twitter, Google, v.v. mà họ nên nhận được với thời gian! :-) Ngay cả với cách tiếp cận ngoại lệ, mã lỗi vẫn có thể có giá trị để phân loại thêm một ngoại lệ. Ví dụ, nếu bạn có một ValidationException tùy chỉnh, bạn có thể có các mã lỗi để mô tả chi tiết kiểu xác thực thất bại như trái ngược với việc tạo một kiểu ngoại lệ tùy chỉnh mới cho mỗi kịch bản xác thực. – WayneC

Các vấn đề liên quan