Vị trí có thể chấp nhận của gốc thành phần bằng cách sử dụng bộ chứa phụ thuộc (DI) và bộ đảo ngược của bộ điều khiển (IoC)

Tôi đã đọc ở một số nguồn, bao gồm blog 'Ploeh' của Mark Seemann về cách vị trí gốc của thành phần của bộ chứa IoC càng gần càng tốt với điểm vào của ứng dụng.

Trong thế giới .NET, các ứng dụng này dường như thường được coi là các dự án Web, dự án WPF, ứng dụng bảng điều khiển, những thứ có giao diện người dùng thông thường (đọc: không phải dự án thư viện).

Có thực sự đi ngược lại lời khuyên hiền triết này khi đặt gốc thành phần tại điểm vào của dự án thư viện, khi nó đại diện cho điểm vào logic của một nhóm các dự án thư viện và khách hàng của nhóm dự án như đây là công việc của người khác , tác giả nào không thể hoặc sẽ không thêm gốc thành phần vào dự án của họ (dự án UI hoặc một dự án thư viện khác, thậm chí)?

Tôi quen thuộc với Ninject như là một triển khai bộ chứa IoC, nhưng tôi tưởng tượng nhiều người khác làm việc theo cách tương tự để họ có thể quét một mô-đun chứa tất cả các cấu hình ràng buộc cần thiết. Điều này có nghĩa là tôi có thể đặt một mô-đun ràng buộc trong dự án thư viện của riêng mình để biên dịch với đầu ra của dự án thư viện chính của tôi và nếu khách hàng muốn thay đổi cấu hình (một trường hợp không thể xảy ra trong trường hợp của tôi), họ có thể thả một dll thay thế để thay thế thư viện với các mô-đun ràng buộc.

Điều này dường như để tránh các khách hàng phổ biến nhất phải đối phó với các gốc thành phần và nội dung tiêm phụ thuộc và sẽ tạo ra API sạch nhất cho nhóm dự án thư viện.

Tuy nhiên, điều này dường như bay trước sự khôn ngoan thông thường về vấn đề này. Có phải hầu hết các lời khuyên ngoài kia đều đưa ra giả định rằng nhà phát triển cũng có sự phối hợp với sự phát triển của dự án UI, chứ không phải là trường hợp của tôi, trong đó tôi chỉ phát triển thư viện cho người khác sử dụng?

Phương pháp tiếp cận mô-đun ràng buộc của bạn là giải pháp tốt nhất. Nếu máy khách không thể thay đổi cấu hình, việc sử dụng DI là đáng nghi ngờ, đối với thư viện của bạn cụ thể.

Nếu bạn muốn tạo một thư viện để phát hành ra công chúng, có lẽ bạn không muốn khách hàng đối phó với sự phức tạp hoặc cứng nhắc của hệ thống DI cụ thể mà bạn ưa thích tại thời điểm này. Thư viện là tốt nhất khi chúng là các thành phần cấp thấp hơn có thể được sử dụng mà không cần nhiều phụ thuộc, hoặc đào tạo mở rộng. Bất kỳ hệ thống DI nào bạn chọn sẽ thay đổi theo thời gian và có thể không tương thích với các ứng dụng khách.

Một thư viện được coi là một hộp đen với API dành riêng cho miền rõ ràng. Không có vấn đề gì với việc sử dụng bất kỳ công cụ hoặc mẫu nào bạn cần trong thư viện, kể cả DI, miễn là nó không bị rò rỉ cho khách hàng và hạn chế anh ta theo một cách nào đó.

Nếu có nhu cầu cung cấp khả năng mở rộng hoặc thay đổi cấu hình thư viện, vẫn có thể được thực hiện mà không cần chia sẻ một gốc thành phần giữa thư viện và máy khách.

Việc bạn có thể chứng minh thư viện của mình tùy thuộc vào thư viện bên thứ 3 khác chỉ để triển khai DI trong thư viện của bạn hay không, là một vấn đề khác, nhưng hãy nhớ rằng chính mẫu DI có thể được thực hiện mà không cần phụ thuộc.

Nếu bạn đang phát triển thư viện (không phải ứng dụng) để người khác sử dụng, bạn vẫn nên thực hiện tiêm phụ thuộc. Đối với tôi thuật ngữ "tiêm phụ thuộc" chỉ là một tập hợp thực hành dẫn đến sự phân tách tốt hơn các mối quan tâm và khớp nối lỏng lẻo. Đây là những gì làm cho thư viện của bạn có cấu trúc tốt và dễ dàng kiểm tra (hầu hết thời gian).

Liên quan đến bộ chứa IoC, tôi không thấy có hại gì khi có bộ chứa IoC trong dự án thư viện. Ở đâu đó bạn sẽ có một gốc thành phần (một điểm nhập cảnh) vào thư viện của bạn, vì vậy với tôi, nó hoàn toàn hợp lý để kết nối các phụ thuộc của bạn trong thư mục gốc. Làm thế nào bạn làm điều đó là hoàn toàn tùy thuộc vào bạn.

Ví dụ, gần đây tôi đã sử dụng một thư viện để chụp chữ ký và thư viện để quét mã vạch. Cả hai đều là các thư viện interop đơn giản (trình bao bọc COM). Mỗi thư viện yêu cầu tôi khởi tạo nó trước khi tôi có thể làm bất cứ điều gì. Ví dụ:

var isReady = _signatureCapture.Initialise()
if (isReady)
{
   // Do stuff
}

Thư viện quét mã vạch rất giống nhau:

_scanner.Initialise();
_scanner.OnScan += OnScanHandler;

Tôi đã và đang sử dụng cả hai thư viện và tôi không biết liệu họ có sử dụng bộ chứa IoC hay không. Tuy nhiên tôi biết rằng các điểm vào thư viện nằm trong các Initialisephương thức. Tôi đoán rằng tất cả các phụ thuộc được nối dây trong Initialisephương thức, phục vụ như một gốc thành phần.

Nếu bạn lo lắng về việc dựa vào bộ chứa IoC của bên thứ ba, bạn có thể thực hiện với việc triển khai đơn giản hơn nhiều. Các nhà phát triển thường lo lắng về việc thư viện trở nên lỗi thời hoặc bị thay thế bởi thứ gì đó tốt hơn, nhưng thực tế tôi chưa thấy một dự án nào mà nhóm quyết định trao đổi một container IoC cho cái kia.

Cái hay của các thư viện bên ngoài là họ nên làm những gì họ nói họ sẽ làm, đồng thời phơi bày một giao diện đơn giản, đơn giản. Làm thế nào phức tạp để thực hiện nó, không nên là doanh nghiệp của nhà phát triển thực hiện nó. Nếu DI thực sự làm cho công việc của nhà phát triển API ít phức tạp hơn, thì nó có ý nghĩa 100% khi sử dụng nó, miễn là nó được sử dụng đúng cách và mô-đun của nó được khai báo tại điểm vào của API. Khi phát triển một ứng dụng MVC gần đây, tôi đã trừu tượng hóa lớp dữ liệu bằng cách sử dụng mẫu kho lưu trữ và thậm chí còn được trừu tượng hóa bằng cách đặt một lớp dịch vụ ở giữa ứng dụng MVC một lớp kho lưu trữ, cả hai đều là các dự án Thư viện lớp. Tôi đã có Giao diện ICache được ánh xạ tới Lớp Cache cho Bối cảnh dịch vụ của tôi. Ban đầu tôi đã triển khai nó bằng MVC.Web.Cache, nhưng trong lần lặp lại sau, tôi đã đổi nó cho System.r Yoon. bộ nhớ cache và bạn chỉ có thể tưởng tượng quy mô của Refactor đó sẽ lớn đến mức nào khi sử dụng DI sử dụng của tôi. Vì vậy, lời khuyên của tôi; "Cứ liều thử đi".