Giữ mọi thứ được kết hợp lỏng lẻo và có thể mở rộng: Quá nhiều lớp, ROI quá nhỏ?

Question

tôi (bây giờ hơn bao giờ hết) thấy các nhà phát triển viết một lượng lớn các lớp như:

implementation PresentationLayer -> 
    interface IMyDTO -> 
     implementation MyDTO -> 
      interface IMyService -> 
       implementation MyService -> 
        interface IMyDomainRepository -> 
         implementation MyDomainRepository -> 
          interface IMyDomainObject -> 
           implementation MyDomainObject -> 
            interface IMyIndependentStorageLayer -> 
             implementation MyMSSQLStorageLayer 

Nhìn qua blog C#, điều này dường như là điều tốt nhất kể từ khi bánh mì cắt lát. Về cơ bản, mọi thứ được kết hợp lỏng lẻo. Không sử dụng trực tiếp đối tượng miền. Chạy mọi thứ thông qua một lớp dịch vụ. Truy cập dữ liệu thông qua một kho lưu trữ. Tất cả các lớp là hoàn toàn độc lập.

Đừng làm cho tôi sai, tôi thích ý tưởng, nhưng không phải là thương mại-off trong thời gian rất lớn, đặc biệt là trên một dự án lớn hơn? ROI có duy trì đủ lớn để biện minh cho điều này không?

Các giải thích tôi đọc là loại khó xử, chẳng hạn như "cách này tôi có thể đính kèm cơ sở dữ liệu khác nếu tôi cần". Có thật không? Tôi không nghĩ rằng đó là một vấn đề phổ biến mà ai đó đột nhiên yêu cầu chuyển từ MSSQL sang Oracle và bây giờ bạn ngồi đó và chúc bạn có một triệu lớp mà tất cả đều không biết lẫn nhau.

Có xu hướng đi quá mức với khớp nối lỏng lẻo hay tôi chỉ đọc sai blog? Bạn cảm thấy thế nào về điều này, và bạn đã có những trường hợp mà bạn thực sự vui vì sau đó bạn đã làm thêm công việc ngay từ đầu?

Answer 1

Rất khó để thiết kế đúng khái niệm liên kết kinh doanh cho một phần mềm. Ý tôi là với ROI có thể chấp nhận được.

Tuy nhiên, đối với tôi, Số lượng lớp hoặc mức độ khớp ghép thấp của một khái niệm phần mềm phụ thuộc vào ngữ cảnh mà phần mềm sẽ được sử dụng!

Nếu bạn chắc chắn về những gì phần mềm phải làm, và có thể sẽ không có sự thay đổi lớn hoặc bổ sung trong tương lai, một ứng dụng ghép nối mức siêu thấp với nhiều lớp không phải là giải pháp. Bởi vì nó làm cho kiến ​​trúc quá phức tạp mà không có lý do gì và thời gian đầu tư cho kiến ​​trúc không mang lại lợi nhuận ...
Mặt khác, nếu bạn biết rằng ứng dụng sẽ phải được tùy chỉnh cho từng khách hàng và chắc chắn sẽ sửa đổi theo chiều sâu, do đó, thời gian dành cho kiến ​​trúc ghép mức thấp là một ý tưởng hay ...
Khớp nối mức thấp có thể thông minh khi bạn muốn sử dụng lại một phần mã cho ứng dụng khác. Trong trường hợp này, thời gian dành cho thiết kế là hoàn toàn sinh lợi, tất nhiên.
Sau đó, tóm lại, tôi sẽ nói rằng tất cả phụ thuộc vào sự phát triển của phần mềm trong tương lai và khả năng tái sử dụng mã cho các ứng dụng khác.
Nhưng đó là cách thực hành tốt nhất đối với tôi không có kiến ​​trúc rất phức tạp về mặt hệ thống.

Answer 2

Rõ ràng, nó có thể là quá hạn, và cần phải biết "nơi dừng" thêm lớp.

Quy tắc chung của tôi là, nếu một lớp không cần bao gồm bất kỳ chức năng/mã quan trọng nào, tôi không cần nó. Điều đó đang được nói, testability là một điều quan trọng, vì vậy nếu một lớp mua cho tôi testability tốt hơn, tôi sẽ thêm nó.

Answer 3

Không có gì trong thiết kế ứng dụng đi kèm mà không có giá. Ở đây giá tăng tính phức tạp. Bạn luôn phải xem qua các tùy chọn của mình trước khi chọn tùy chọn phù hợp nhất với nhu cầu của bạn.

Với điều đó được nói, tôi nghĩ câu hỏi của bạn có vẻ hơi thiên vị. Trong thế giới thực, bạn có thể không thường thấy một khách hàng yêu cầu một loại DB mới, nhưng bạn thường có thể thấy một costumer mới, những người muốn cùng một loại truy cập dữ liệu hơn so với trước đó, nhưng trên một DB khác. Nó không chỉ là về sự thay đổi dễ dàng, mà còn về việc sử dụng lại mã.

Answer 4

Khi đánh giá những điều này, tôi thường thấy hữu ích khi nhìn vào nó qua ống kính của nguyên tắc DRY và xem xét sao chép trong dự án của bạn.

Nếu bạn đang sử dụng kiến ​​trúc phức tạp hơn dự án của mình, bạn sẽ có xu hướng nhìn thấy rất nhiều lớp bên cạnh các lớp khác và truyền cuộc gọi. Điều này lặp lại chính bạn.

Nếu mặt khác bạn đang sử dụng kiến ​​trúc mỏng cho một hệ thống phức tạp, bạn có thể thấy rằng việc tạo chức năng trong một phần của hệ thống không cho phép bạn sử dụng lại chức năng đó trong phần khác, buộc bạn viết nhiều mã rất giống nhau trên khắp nơi. Điều này lặp lại chính bạn.

Theo kinh nghiệm của tôi, nếu bạn thận trọng trong việc xác định trùng lặp và liên tục tái cấu trúc để xóa nó, cấu trúc sẽ tự giới thiệu cho bạn. Ví dụ, bạn bắt đầu với một kiến ​​trúc khá cơ bản nhưng phá vỡ mọi thứ thành các phương thức ngay khi chúng cần được tái sử dụng, và phá vỡ các phương thức vào các lớp ngay khi chúng cần được các lớp khác sử dụng lại. Sau đó, cuối cùng bạn có thể nhận ra rằng 13 lớp Trình trợ giúp/Trình quản lý/Trình xử lý mà bạn đã viết để loại bỏ trùng lặp thực sự trông hơi giống như chúng chịu trách nhiệm có thể được xác định rõ ràng hơn nếu nó đã đi vào lớp Dịch vụ. Có thể khó hiểu khi nào nó đáng giá, nhưng tôi nghĩ chìa khóa thành công trong việc xây dựng một hệ thống với nhiều lớp là rất rõ ràng với những trách nhiệm mà các lớp khác nhau nên có. Bất kỳ lớp nào bạn thêm phải hữu ích cho bạn trong việc giảm độ phức tạp của các hoạt động trong lớp ở trên nó và làm cho nó dễ dàng hơn để dệt chức năng với nhau một cách thanh lịch.

Answer 5

Lấy một dự án ví dụ giả định. Các bài kiểm tra sử dụng các cơ sở dữ liệu SQLite khác nhau cho tốc độ, cơ sở dữ liệu phát triển trên một số máy tính của nhà phát triển là PostgreSQL, cơ sở dữ liệu dàn dựng là một cài đặt Oracle duy nhất, và cơ sở dữ liệu sản xuất có khả năng mở rộng, rất tốn kém và rất khó cấu hình Oracle cụm.

Làm thế nào bạn có thể kéo nó ra mà không tách lớp SQL khỏi lớp nghiệp vụ?

Answer 6

Đó là một xu hướng gần đây và ít khách hàng tiềm năng/kiến ​​trúc sư có kinh nghiệm đang rơi con mồi để nhảy trên băng.

Trong dự án Tôi đang trên, truy cập dữ liệu đi:

Interface Dịch vụ -> Dịch vụ thực hiện -> Đại biểu Interface -> Đại biểu thực hiện -> DAO Interface -> DAO thực hiện -> iBATIS XML.

Trường hợp này là (và là!), Vì hầu hết mã trong bất kỳ phương thức triển khai ủy quyền nào đều là một dòng; nó chỉ được gọi là DAO. Đối với mỗi DAO, chúng tôi có thêm hai lớp và thêm một cấu hình bean, và chúng tôi đã không đạt được gì cả.

Chấp nhận thay đổi, refactor và tiếp tục. Sử dụng càng nhiều lớp càng tốt để tách rời các khái niệm khác nhau ... và sau đó dừng lại. Nếu không có sự hiểu biết bằng cách viết một số mã, ngoại trừ việc nó sẽ làm theo mẫu, hoặc làm chậm và cố gắng hiểu đầy đủ lý do tại sao mẫu đã làm điều đó, hoặc chấp nhận rằng mẫu đó sai cho ứng dụng của bạn và bỏ qua bit đó.

Answer 7

Tôi hiện đang làm việc trên một dự án SOA lớn, nơi mỗi lớp được tách riêng và hầu hết mọi lớp được khởi tạo qua một số nhà máy trừu tượng. Bây giờ chúng tôi đang cố gắng giảm bớt một số chức năng hiện có thành các dịch vụ được lưu trữ riêng biệt, và đó là một cơn ác mộng thực sự đi qua các lớp cố gắng ngoại suy các bit quan trọng bởi vì có một nhấp chuột phải không bao giờ kết thúc> Chuyển đến định nghĩa ...để truy tìm những gì chỉ có 1 dòng mã ở lớp ngoài cùng!

Không có gì sai với việc tách riêng, và chắc chắn ngay cả trong dự án của tôi cũng có nhiều lĩnh vực mà tôi thấy nó hữu ích từ quan điểm kiến ​​trúc. Chỉ cần không được mang đi ... Hãy thực dụng, và cân nhắc những ưu/nhược điểm khi kiểm tra các khu vực bạn đang xem xét để decouple.

Chúc mừng