Mẫu thiết kế - DLL theo chiến lược

Tôi thường thấy mình thiết kế ứng dụng của mình theo cách sau:

1. Một DLL chứa giao diện cho một hệ thống con mong muốn. Ví dụ , Company.Framework.Persistence.dll.
2. Một DLL mới cho mỗi chiến lược (hoặc triển khai ) của hệ thống con nói trên. Ví dụ:
   • Company.Framework.Persistence.MSSQL.dll
   • Company.Framework.Persistence.MySQL.dll
   • Company.Framework.Persistence.FileSystem.dll

Điều này sẽ dẫn đến một giải pháp rất lớn với rất nhiều dự án, nhưng mặt khác, sẽ cho người tiêu dùng cơ hội lựa chọn DLL phù hợp cho nhu cầu của mình.

Nếu chúng ta có một DLL duy nhất được gọi Company.Framework.Persistence.dll, người tiêu dùng sẽ phải tải rất nhiều chiến lược mà anh ta không bao giờ có thể sử dụng. Có mô-đun DLL sẽ giải quyết vấn đề này.

Đây có phải là thực hành tốt? Có một bất lợi với thiết kế này?

Tôi nghĩ rằng những lợi thế của phương pháp này xa, vượt xa bất kỳ nhược điểm nào.

Những gì bạn đang đạt được ở đây là quặng hơn không kém một hoàn hảo "thực hiện" của Itrong SOLIDbằng cách của Stairwaymô hình - đó là để nói, ứng dụng của bạn phụ thuộc "xuống" trên một giao diện được định nghĩa trong Company.Framework.Persistence.dllvà việc triển khai cá nhân mình cũng phụ thuộc "lên" về sự trừu tượng này.

Điều này có nghĩa là ứng dụng của bạn được phân tách cao từ bất kỳ chi tiết triển khai nào (tất nhiên bạn thường muốn soạn biểu đồ thời gian chạy thực tế bằng cách sử dụng IOC Container của một số loại) Tôi đã liên kết một cách đáng xấu hổ với một hình ảnh hiện có của mẫu này từ một câu trả lời khác về chủ đề này trên Stack Overflow:

Trong cuốn sách Mã thích ứng thông qua C # , tác giả đã nói về cách tiếp cận này và đặc biệt gọi nó là một việc nên luôn luôn được thực hiện bởi vì nó cung cấp mức độ tách rời cao như vậy. ( ví dụ )

Một lợi thế khác có thể là có thể vá các triển khai riêng lẻ mà không phải lo lắng rằng bạn có thể đã ảnh hưởng đến những người khác, mặc dù đây là một vấn đề khá nhỏ một khi bạn đã siêng năng kiểm tra hồi quy; cũng có thể triển khai các triển khai riêng lẻ trong các thư mục con cũng có thể chứa các phiên bản cụ thể của bất kỳ phụ thuộc bên thứ 3 nào mà chúng có thể cần có thể giúp giữ mọi thứ được tổ chức tốt.

Về nhược điểm thực sự duy nhất tôi có thể nghĩ đến với phương pháp này là về mặt lý thuyết có thể thay đổi giao diện Company.Framework.Persistence.dll(cùng với các nhị phân của ứng dụng của bạn) và bỏ qua việc cập nhật các dll thực hiện tương ứng sẽ dẫn đến lỗi thời gian chạy cho người dùng của bạn.

Đã từng có lỗi khi làm chính xác điều này trong quá khứ, tôi có thể nói rằng đây thực sự chỉ là điều có thể xảy ra nếu bạn rất bất cẩn :)

Tôi cũng làm theo cách đó

Các dự án / dll về cơ bản là miễn phí và làm cho mã dễ đọc hơn và dễ sử dụng hơn.

Tôi đã biết mọi người sử dụng một DLL lớn duy nhất và phân biệt với các không gian tên. Nhưng như bạn nói họ phải triển khai mã không sử dụng, tôi không thấy bất kỳ lợi ích nào đối với thực tiễn và nhiều nhược điểm như

• thay đổi để thực hiện một yêu cầu biên dịch lại của người khác
• mã không sử dụng được triển khai để sống (nguy cơ lỗi)
• mã kiểm tra được triển khai trực tiếp (giả, v.v, có nguy cơ lỗi, cấu hình sai)
• mã lỗi thời yêu cầu tái cấu trúc để xóa, (giả sử chúng ta không sử dụng MySQL nữa)
• phải kiểm tra mã chưa sử dụng trước khi triển khai (chúng tôi đang kiểm tra phải không?)
• tái cấu trúc có thể gây ra lỗi biên dịch trong thành phần không sử dụng (giả sử chúng ta thay đổi giao diện)

Tôi có thể cắt các góc và đặt triển khai cụ thể với giao diện cho các ứng dụng nhỏ nếu nó tránh được một dự án chỉ chứa một giao diện duy nhất. Nhưng bình thường tôi thấy các giao diện đi với các mô hình. Vì vậy tôi sẽ có

• Company.Framework.Models.dll (bao gồm giao diện cho sự bền bỉ)
• Company.Framework.Persistence.MyQuery.dll (mô hình ref, nhưng dù sao cũng cần)
• Company.Framework.Persistence.Mock.dll (mô hình ref, nhưng dù sao cũng cần)

hoặc (phím tắt xấu!)

• Company.Framework.Models.dll (không bao gồm các giao diện)
• Company.Framework.Persistence.MyQuery.dll (bao gồm giao diện kiên trì, mô hình ref)
• Company.Framework.Persistence.Mock.dll (mô hình ref và sql, nhưng nó không được triển khai để sống)

Obvs, khá đơn giản để cấu trúc lại các giao diện nếu ứng dụng tăng kích thước / độ phức tạp

Ưu điểm của chiến lược hai là giảm thiểu địa ngục dll.

Thông thường Company.Framework.Persistence.MyQuery.dll sẽ phụ thuộc vào một số dll để giao tiếp với MySql. Nếu tôi không có hứng thú với MySql, tại sao tôi nên tải xuống dll từ MySql?

Hãy nói rằng khuôn khổ của bạn hỗ trợ 20 nhà cung cấp lưu trữ khác nhau. Hầu hết người dùng chỉ sử dụng một. Vì vậy, tất cả người dùng phải đi và nhận 19 dll, họ sẽ không bao giờ sử dụng chỉ để biên dịch khung của bạn.

Theo chiến lược hai, bạn cho phép người dùng của bạn chỉ cài đặt dll mà họ sẽ sử dụng và do đó giảm thiểu địa ngục dll.