Các quy ước đặt tên DAL, BAL và Lớp UI [đã đóng]

Tôi đang phát triển một Ứng dụng Web điển hình với các lớp sau

1. Lớp giao diện người dùng (MVC)
2. Lớp logic nghiệp vụ (BAL)
3. Lớp truy cập dữ liệu (DAL)

Mỗi lớp có đối tượng DTO riêng bao gồm BAL và DAL. Câu hỏi của tôi về điều này là như sau

1. DTO được trả về bởi DAL chỉ đơn giản được chuyển đổi thành DTO tương ứng trong BAL và được gửi đến Lớp UI. Cả hai thuộc tính và cấu trúc của các đối tượng DTO đều giống nhau trong một số trường hợp. Trong các kịch bản như vậy, tốt hơn là chỉ cần trả DTO trong DAL cho lớp UI mà không bao gồm một đối tượng trung gian.

2. Cách tốt nhất để đặt tên cho các đối tượng DTO này và các đối tượng khác trong mỗi lớp là gì. Tôi có nên sử dụng một số tiền tố như DTOName, ServiceName không? Lý do tại sao tôi yêu cầu sử dụng tiền tố là vì nếu không phải các lớp trong Giải pháp của tôi đụng độ với các lớp khác trong Khung và với tiền tố, tôi có thể dễ dàng hiểu được mỗi lớp thuộc về đâu không?

Lời nói đầu

Hy vọng điều này là hiển nhiên, nhưng ... trong các không gian tên được đề xuất bên dưới, bạn sẽ thay thế MyCompanyvà MyProjectbằng tên thật của công ty và dự án của bạn.

DTO

Tôi sẽ khuyên bạn nên sử dụng các lớp DTO giống nhau trên tất cả các lớp. Ít điểm bảo trì theo cách đó. Tôi thường đặt chúng dưới một MyCompany.MyProject.Modelskhông gian tên, trong dự án VS cùng tên của chúng. Và tôi thường đặt tên cho chúng đơn giản theo tên thực thể trong thế giới thực mà chúng đại diện. (Lý tưởng nhất là các bảng cơ sở dữ liệu cũng sử dụng cùng tên, nhưng đôi khi nó có ý nghĩa để thiết lập lược đồ hơi khác một chút ở đó.)

Ví dụ: Person, Address,Product

Phụ thuộc: Không (ngoài thư viện .NET hoặc thư viện trợ giúp tiêu chuẩn)

DAL

Sở thích cá nhân của tôi ở đây là sử dụng một nhóm các lớp DAL phù hợp với các lớp DTO, nhưng trong một MyCompany.MyProject.DataAccesskhông gian tên / dự án. Tên lớp ở đây kết thúc bằng một Enginehậu tố để tránh xung đột. (Nếu bạn không thích thuật ngữ đó, thì DataAccesshậu tố cũng sẽ hoạt động tốt. Chỉ cần phù hợp với bất cứ điều gì bạn chọn.) Mỗi ​​lớp cung cấp các tùy chọn CRUD đơn giản đánh vào cơ sở dữ liệu, sử dụng các lớp DTO cho hầu hết các tham số đầu vào và kiểu trả về (bên trong chung chung Listkhi có nhiều hơn một, ví dụ, trả về từ một Find()phương thức).

Ví dụ: PersonEngine, AddressEngine,ProductEngine

Phụ thuộc: MyCompany.MyProject.Models

BAL / BLL

Cũng là một ánh xạ một-một ở đây, nhưng trong một MyCompany.MyProject.Logickhông gian tên / dự án và với các lớp có một Logichậu tố. Đây phải là lớp duy nhất gọi DAL! Các lớp học ở đây thường chỉ là một sự truyền qua đơn giản cho DAL, nhưng nếu & khi các quy tắc kinh doanh cần được thực hiện, thì đây là nơi dành cho nó.

Ví dụ: PersonLogic, AddressLogic,ProductLogic

Dependencies: MyCompany.MyProject.Models,MyCompany.MyProject.DataAccess

API

Nếu có một lớp API dịch vụ web, tôi sử dụng cùng một cách tiếp cận một, nhưng trong một MyCompany.MyProject.WebApikhông gian tên / dự án, với Serviceshậu tố lớp. (Trừ khi bạn đang sử dụng API Web ASP.NET, trong trường hợp đó, tất nhiên bạn sẽ sử dụng Controllerhậu tố thay thế).

Ví dụ: PersonServices, AddressServices,ProductServices

Phụ thuộc : MyCompany.MyProject.Models, MyCompany.MyProject.Logic(không bao giờ bỏ qua điều này bằng cách gọi trực tiếp cho DAL!)

Một quan sát về logic kinh doanh

Dường như ngày càng phổ biến hơn đối với mọi người khi bỏ BAL / BLL, và thay vào đó thực hiện logic kinh doanh ở một hoặc nhiều lớp khác, bất cứ nơi nào có ý nghĩa nhất. Nếu bạn làm điều này, chỉ cần chắc chắn rằng (1) tất cả các mã ứng dụng đi qua (các) lớp với logic nghiệp vụ và (2) nó rõ ràng và / hoặc được ghi chép rõ ràng trong đó từng quy tắc kinh doanh cụ thể đã được thực hiện. Nếu nghi ngờ, đừng thử điều này ở nhà.

Lưu ý cuối cùng về Kiến trúc cấp doanh nghiệp

Nếu bạn đang ở trong một công ty lớn hoặc trong tình huống khác có cùng bảng cơ sở dữ liệu được chia sẻ trên nhiều ứng dụng, thì tôi khuyên bạn nên để MyProjectphần đó ra khỏi các không gian tên / dự án trên. Bằng cách đó, các lớp đó có thể được chia sẻ bởi nhiều ứng dụng ngoại vi (và cả các tiện ích hậu trường như Windows Services). Nhưng chỉ làm điều này nếu bạn có giao tiếp giữa các nhóm mạnh mẽ và thử nghiệm hồi quy tự động triệt để tại chỗ !!! Mặt khác, một nhóm thay đổi thành thành phần cốt lõi được chia sẻ có khả năng phá vỡ ứng dụng của nhóm khác.

Tôi thường xây dựng ứng dụng như

ProjectName.Core            // "framework"/common stuff
|- Extenders
|- Gravatar.cs

ProjectName.DataProvider    // database provider layer
|- Migrations
|- ApplicationDbContext.cs  // entity framework

ProjectName.Domain          // database objects
|- Post.cs
|- Tag.cs

ProjectName.Services        // validations, database stuff
|- PostService.cs

Nó có phần giống với Sharp-Lite .

Về tiền tố, tôi ghét chúng. Nguyên tắc mã hóa nội bộ của Microsoft cũng ghét chúng. Ngoài ra còn có một công cụ gọi là StyleCop cũng phàn nàn về tiền tố.