Khi nào một lớp hoặc mô-đun nên ở trong một hội / DLL riêng biệt?

Có hướng dẫn nào để quyết định khi nào một lớp nên ở trong hội đồng / DLL riêng của nó không? Tôi thường thấy hai trường phái tư tưởng:

1) Mỗi "nhóm" các lớp thuộc về DLL riêng của nó, ví dụ như Kho, Dịch vụ, DTO, Cơ sở hạ tầng, v.v.

2) Mọi thứ phải nằm trong một DLL duy nhất nhưng được phân tách thông qua các không gian tên / thư mục, ví dụ: có DLL "Core" với các không gian tên bổ sung, ví dụ như Core.Repositories, Core.Service, Core.DTO, v.v.

Trong công việc, chúng tôi chỉ gộp tất cả mọi thứ trong một hội duy nhất gọi là "Kinh doanh". Có một số thư mục nhưng không có sự phân tách thực sự - các đối tượng kinh doanh (có logic, một số trong đó thậm chí không phải là các lớp) được gộp trong một thư mục "BusinessObjects" mà không cần quan tâm. Những thứ được sử dụng trong nhiều lớp nằm trong thư mục "Lõi". Các tiện ích nằm trong thư mục "Tiện ích", cơ sở hạ tầng truy cập dữ liệu là thư mục "Dữ liệu" - bạn hiểu ý tưởng.

Đối với một mô-đun mới tôi đang làm việc tôi muốn / cần phải có một lớp truy cập dữ liệu riêng biệt (nghĩ rằng việc triển khai Kho lưu trữ thô sơ) nhưng tôi không muốn ném nó vào thư mục "BusinessObjects" với 160 (!) Khác các lớp học ở đó. Đồng thời tôi lo lắng về việc tạo Thư viện lớp mới vì mọi người đều quen với việc nhồi một lớp trong Thư viện duy nhất; một thư mục / không gian tên có thể làm việc tuy nhiên.

c# architecture directory-structure

— Wayne Molina
nguồn

Câu trả lời:

Tôi thấy tốt hơn là có nhiều dự án hơn (tức là tập hợp) với các lớp được chia theo danh mục trong mỗi dự án hơn là một dự án với tất cả các lớp này trong các không gian tên riêng biệt. Bạn nên nhắm đến các dự án của bạn có thể tái sử dụng và thể hiện các lớp khác nhau trong một ứng dụng. Sau đó, bạn có thể sử dụng lại các dự án này một cách khả thi trong các ứng dụng trong tương lai mà không cần phải bao gồm cả nhóm các lớp không cần thiết.

Ví dụ, dựa trên những gì bạn đã đề cập, tôi chắc chắn sẽ có các dự án sau:

Cốt lõi
Dữ liệu
Tên miền (hoặc BusinessObjects)
Dịch vụ
Tiện ích (hoặc Người trợ giúp)

— Bernard
nguồn

Đáng tiếc tôi không thể bỏ phiếu trả lời. Đây chính xác là những gì được khuyên trong công ty của chúng tôi. Kết quả là có 6 dự án hoặc hơn, ví dụ như đối với trang web kích thước trung bình, bạn không thể duy trì phân cấp dựa trên tính năng của các thư mục, v.v. Kết quả là bạn kết thúc với sáu dự án với mỗi dự án là một mớ hỗn độn lớn không thể điều hướng được đống tệp. Thông thường những người tư vấn điều này chưa bao giờ thử cấu trúc dựa trên tính năng của các dự án trên các dự án tương đối lớn (xin lỗi vì đánh giá trực tiếp nhưng xử lý kết quả của việc vượt quá như vậy là một nỗi đau thực sự). Các câu trả lời jammycakes tư vấn cách tiếp cận chính xác.

— alehro

Phân chia các lớp theo thể loại là những gì dẫn đến sự lộn xộn trong các dự án lớn. Chia chúng theo tính năng / khía cạnh. Sau đó, không gian tên sẽ chỉ phản ánh sự phân chia này. Và toàn bộ cấu trúc sẽ phản chiếu từ vựng từ đặc điểm kỹ thuật. Phân chia các lớp theo thể loại cũng giống như thêm chữ viết tắt vào tên biến - thường là mùi hôi.

— alehro

Thật dễ dàng để lạm dụng cả hai giải pháp được đề xuất (nghĩa là quá nhiều dự án hoặc quá ít). Tìm kiếm một sự cân bằng tốt trong đó khả năng tái sử dụng và khớp nối thấp được lưu ý sẽ dẫn đến một cái gì đó dễ kiểm tra và duy trì hơn.

— Bernard

"Chú Bob" Martin của Clean Code, danh tiếng Nguyên tắc RẮN đã nêu ra ba nguyên tắc ở đây :

Nguyên tắc tương đương tái sử dụng phát hành: Hạt tái sử dụng là hạt phát hành.
Nguyên tắc đóng cửa chung: Các lớp thay đổi cùng nhau được đóng gói cùng nhau.
Nguyên tắc tái sử dụng chung: Các lớp được sử dụng cùng nhau được đóng gói cùng nhau.

Nguyên tắc chung là bạn nên giữ số lượng dự án trong giải pháp của mình càng thấp càng tốt. Chỉ tách chúng ra nếu bạn cần làm như vậy để triển khai một hoặc nhiều câu chuyện người dùng cụ thể hoặc nếu có một hội đồng duy nhất gây ra các vấn đề về hiệu suất có thể đo lường được (thường là khi chúng có kích thước lên tới vài megabyte).

— máy làm bánh mỳ
nguồn

+1 những nguyên tắc này là những hướng dẫn tốt. Việc tách các lớp thành các tổ hợp khác nhau sẽ đưa ra các xem xét thiết kế bổ sung (ví dụ: phiên bản nào của mỗi tổ hợp được phép làm việc cùng nhau) làm tăng cơ sở mã tổng thể do đó làm tăng chi phí bảo trì.

— Ben

Tuy nhiên, ngoài các nguyên tắc này, tôi sẽ nói thêm rằng thường thì nên gói mã có khả năng được thay thế hoặc hoán đổi trong một cụm riêng biệt. Mã này sẽ được hưởng lợi từ các cân nhắc bổ sung cần thiết để ghép các cụm riêng biệt và việc tách nó sẽ giúp kiểm tra và so sánh các phiên bản khác nhau dễ dàng hơn.

— Ben

Có, nhưng đảm bảo rằng có một yêu cầu chính hãng để nó được thay thế hoặc hoán đổi. Ví dụ: khung và thư viện bên thứ ba - các gói NuGet và tương tự - thường cần hỗ trợ nhiều thùng chứa IOC và nhiều khung ghi nhật ký. Mặt khác, đối với mã người dùng, các tóm tắt như vậy thường hoàn toàn là đầu cơ, không cần thiết và gây cản trở và không bao giờ kết thúc trong những trường hợp hiếm hoi khi chúng thực sự cần thiết.

— jammycakes

"Chỉ tách chúng ra nếu bạn cần làm như vậy để triển khai một hoặc nhiều câu chuyện người dùng cụ thể hoặc nếu có một hội đồng duy nhất gây ra các vấn đề về hiệu suất có thể đo lường được (thường là khi chúng có kích thước lên tới vài megabyte)." - hoàn toàn ngẫu nhiên và không có căn cứ trong lời khuyên thực tế

— hyankov

Tôi xin lỗi, nhưng chính xác thì "hoàn toàn ngẫu nhiên và không có căn cứ trong thực tế" về nó là gì? Tôi đã đăng câu trả lời này sau nhiều năm làm việc về các giải pháp được chia thành nhiều dự án hơn mức cần thiết mà không có lý do gì khác ngoài đó là cách bạn được cho là làm điều đó. Kết quả? Thời gian biên soạn băng hà và một loạt địa ngục phụ thuộc (đặc biệt là trong những ngày trước NuGet). Việc chia mọi thứ thành các tổ hợp riêng biệt có một chi phí và nếu không có bất kỳ lợi ích nào để bù đắp chi phí đó, thì đó chỉ là một trường hợp ăn cắp từ doanh nghiệp.

— jammycakes 17/11/17

Một số hoàng tử hướng dẫn khác mà tôi làm việc với:

Bạn có nghĩ rằng bạn sẽ sử dụng lại mã này trong các dự án khác không? Đối với một nhóm các ứng dụng web có liên quan, chúng tôi có một mô-đun liên quan đến tài khoản người dùng mà tất cả các ứng dụng đã sử dụng, vì tất cả chúng đều sử dụng cùng một mô hình cho tài khoản người dùng và đăng nhập. Tôi đã làm những điều tương tự với các thư viện hình học và toán học và sử dụng lại chúng trong nhiều ứng dụng, chỉ bằng cách bao gồm DLL.
Bạn có muốn sửa đổi / triển khai mã này mà không cần triển khai lại / biên dịch lại toàn bộ dự án không? Đôi khi thật hữu ích khi chỉ cần xây dựng lại mô-đun, triển khai và khởi động lại ứng dụng web.

Có vẻ như trong trường hợp của bạn, một Kho lưu trữ cơ bản và chung chung có thể hữu ích một lần nữa trong tương lai, có thể đáng để tách nó thành một DLL mới nếu bạn có thể.

— Thất vọngWithFormsDesigner
nguồn

Tôi nghĩ rằng điểm thứ hai của bạn là thực sự hợp lý. Chia thành các mô-đun nên hỗ trợ thời gian phát triển / thử nghiệm và biên dịch.

— WM