Các khung tiêm phụ thuộc có gây ra rủi ro phụ thuộc không?

Tôi đã tái cấu trúc một hệ thống hiện có để sử dụng phương pháp tiêm phụ thuộc và công việc đó đã diễn ra suôn sẻ.

Sau một thời gian, tôi nhận thấy rằng một số lượng lớn các thư viện nội bộ đã trở nên phụ thuộc vào khung DI tôi đã sử dụng. Kết quả là toàn bộ dự án hiện phụ thuộc vào khuôn khổ của bên thứ ba này.

Tôi thấy một sự trớ trêu trong việc tách rời tất cả các phụ thuộc bằng cách làm cho chúng phụ thuộc vào một thư viện chia sẻ.

Phản ứng đầu tiên của tôi là tạo ra một thư viện bao bọc xung quanh khung phụ thuộc. Do đó, tôi có thể thay thế khung này nếu cần. Sau khi ước tính công việc liên quan, tôi nhận ra rằng API kết quả sẽ tương tự như khung hiện có và do đó làm cho việc thay thế nó trở nên khó khăn hơn. Thế là tôi từ bỏ ý tưởng.

Mối quan tâm của tôi là khung DI tôi đang sử dụng trở nên lỗi thời hoặc cần thay thế.

Có tồn tại một mô hình phát triển khi làm việc với DI làm giảm sự ghép nối giữa dự án và khung DI không?

Bạn hoàn toàn chính xác - sử dụng khung DI có thể sẽ khiến mã của bạn phụ thuộc vào điều đó. Trên thực tế, điều đó quá đáng ngạc nhiên, vì điều này thường đúng với mọi thư viện khung hoặc nền tảng khác, đặc biệt khi lib đó hỗ trợ dự án của bạn với một số tính năng chung được sử dụng ở mọi nơi trong mã của bạn. Ví dụ: khi bạn quyết định sử dụng khung UI hoặc khung Web nhất định, quyết định này khó có thể thay đổi sau đó ngay khi bạn xây dựng một số lượng mã nhất định dựa trên thư viện đó. Khi bạn quyết định sử dụng một lớp cụ thể (có thể không chuẩn) String, bạn không thể dễ dàng thay đổi quyết định đó sau này. Một quyết định như vậy là một kiến ​​trúc, nó giống như chọn một ngôn ngữ lập trình nhất định và cố gắng thay đổi quyết định đó sau khi bạn đã viết> 100K dòng mã.

Có tất cả các mã của bạn phụ thuộc vào một khung nhất định có thể không phải là vấn đề miễn là nó làm những gì bạn mong đợi từ nó và miễn là nó được duy trì đúng cách. Nhưng nó có thể trở thành một vấn đề nếu không phải như vậy. Có một số chiến lược làm thế nào để đối phó với tình huống đó:

• chọn một khung từ một nhà cung cấp mà bạn tin tưởng rằng anh ta có thể cung cấp cho bạn các bản cập nhật và bản phát hành mới trong vài năm kể từ bây giờ

• chọn một khung nguồn mở có đủ vài dòng mã (và giấy phép phù hợp), để bạn có thể tự mình bảo trì, do nhà cung cấp biến mất khỏi thị trường

• viết khuôn khổ của riêng bạn

• sống với tình huống miễn là nhà cung cấp có sẵn và khi anh ta thực sự biến mất, hãy chọn một khung khác và cố gắng tạo một bộ chuyển đổi mô phỏng khung cũ bằng cách sử dụng khung mới

Ý tưởng tạo ra một thư viện trình bao bọc trước đó hoàn toàn không mới, nhưng tôi hiếm khi thấy rằng nó hoạt động, vì bạn sẽ phải đưa ra các giả định cho một tình huống trong tương lai mà bạn không biết liệu nó sẽ đánh vào bạn và khi nào khuôn khổ "mới" sẽ như thế nào. Mặt khác, vài năm trước, chúng tôi đã trao đổi thành công một khung UI hoàn chỉnh trong dự án C ++ với ~ 120K dòng mã bằng cách áp dụng chiến lược bộ điều hợp tôi đã đề cập ở trên.

Tiêm xây dựng thông thường không yêu cầu một khuôn khổ nào cả. Điều duy nhất bạn mất đi là khả năng tập trung các phụ thuộc của bạn vào một tệp cấu hình.

Các thùng chứa DI là một mẫu "phần mềm doanh nghiệp", được sử dụng khi biểu đồ đối tượng rất lớn và phức tạp. Tôi nghi ngờ rằng 95% ứng dụng không yêu cầu nó.

Tôi không nghĩ khung DI có thể thực sự trở nên lỗi thời bất cứ lúc nào sớm. Điều gì sẽ xảy ra để làm cho nó lỗi thời?

• Một phát minh của một mô hình mới và thông minh hơn có thể? Tuy nhiên, nó sẽ trông giống như, nó sẽ đòi hỏi những thay đổi lớn hơn nhiều trong mã.
• Một sự thay đổi trong ngôn ngữ có thể? Thậm chí tệ hơn.

Tôi nói rằng DI hiện tại đã đủ trưởng thành và tôi không biết nhiều chuyện xảy ra ở đó. Bạn chưa chỉ định ngôn ngữ của mình, vì vậy, nói về Guice , nó không gây khó chịu và hoạt động với các chú thích Java tiêu chuẩn (cũng sử dụng ngôn ngữ riêng của chúng cho những thứ không được chuẩn hóa, nhưng bạn hiếm khi cần nó). Nó có nguồn mở, được sử dụng rộng rãi và được cấp phép bởi Apache. Điều gì có thể là vấn đề?

Tôi khá chắc chắn rằng việc thay đổi khung DI sẽ dễ dàng hơn so với việc thay đổi bất kỳ thư viện nào khác (ví dụ: thay đổi UI có nghĩa là nhiều công việc hơn).