Có phải tiêm phụ thuộc của Poor Man là một cách tốt để giới thiệu khả năng kiểm tra cho một ứng dụng cũ không?

Trong năm vừa qua, tôi đã tạo ra một hệ thống mới bằng cách sử dụng Dependency Injection và bộ chứa IOC. Điều này đã dạy tôi rất nhiều về DI!

Tuy nhiên, ngay cả sau khi tìm hiểu các khái niệm và các mẫu thích hợp, tôi coi đó là một thách thức để tách mã và giới thiệu một thùng chứa IOC vào một ứng dụng cũ. Ứng dụng này đủ lớn đến mức một triển khai thực sự sẽ trở nên quá sức. Ngay cả khi giá trị được hiểu và thời gian được cấp. Ai đã dành thời gian cho những thứ như thế này ??

Mục tiêu của khóa học là đưa các bài kiểm tra đơn vị vào logic kinh doanh!
Logic nghiệp vụ được đan xen với các cuộc gọi cơ sở dữ liệu ngăn chặn thử nghiệm.

Tôi đã đọc các bài báo và tôi hiểu được sự nguy hiểm của Tiêm phụ thuộc của Người nghèo như được mô tả trong bài viết này của Los Techies . Tôi hiểu nó không thực sự tách rời bất cứ điều gì.
Tôi hiểu rằng nó có thể liên quan đến việc tái cấu trúc toàn hệ thống vì việc triển khai đòi hỏi phải phụ thuộc mới. Tôi sẽ không xem xét sử dụng nó trên một dự án mới với bất kỳ kích thước nào.

Câu hỏi: Có ổn không khi sử dụng DI của Poor Man để giới thiệu khả năng kiểm tra ứng dụng cũ và bắt đầu bóng lăn?

Ngoài ra, việc sử dụng DI của Poor Man như một cách tiếp cận cơ bản để tiêm phụ thuộc thực sự có phải là một cách có giá trị để giáo dục về nhu cầu và lợi ích của nguyên tắc này không?

Bạn có thể cấu trúc lại một phương thức có sự phụ thuộc cuộc gọi cơ sở dữ liệu và trừu tượng mà gọi đến phía sau một giao diện không? Chỉ cần có sự trừu tượng hóa đó sẽ làm cho phương thức đó có thể kiểm tra được do việc triển khai giả có thể được truyền qua quá tải hàm tạo.

Cuối cùng, một khi nỗ lực đạt được những người ủng hộ, dự án có thể được cập nhật để triển khai một thùng chứa IOC và các nhà xây dựng sẽ ở ngoài đó để thực hiện các tóm tắt.

Bài phê bình về tiêm chích của Poor Man trong NerdDinner ít liên quan đến việc bạn có sử dụng DI Container hay không so với việc thiết lập các lớp học của bạn một cách chính xác.

Trong bài báo, họ nói rằng

public class SearchController : Controller {

    IDinnerRepository dinnerRepository;

    public SearchController() : this(new DinnerRepository()) { }

    public SearchController(IDinnerRepository repository) {
        dinnerRepository = repository;
    }
}

là không chính xác bởi vì, trong khi hàm tạo đầu tiên cung cấp cơ chế dự phòng thuận tiện để xây dựng lớp, nó cũng tạo ra một phụ thuộc ràng buộc chặt chẽ với DinnerRepository.

Tất nhiên, biện pháp khắc phục chính xác không phải là, như Los Techies gợi ý, để thêm một thùng chứa DI, mà là để loại bỏ các hàm tạo vi phạm.

public class SearchController : Controller 
{
    IDinnerRepository dinnerRepository;

    public SearchController(IDinnerRepository repository) {
        dinnerRepository = repository;
    }
}

Các lớp còn lại bây giờ có các phụ thuộc của nó được đảo ngược đúng. Bây giờ bạn có thể tự do tiêm những phụ thuộc đó theo cách bạn muốn.

Bạn đưa ra một giả định sai ở đây về "DI của người nghèo" là gì.

Tạo một lớp có hàm tạo "lối tắt" vẫn tạo khớp nối không phải là DI của người nghèo.

Không sử dụng một thùng chứa, và tạo ra tất cả các mũi tiêm và ánh xạ bằng tay, là người nghèo của DI.

Thuật ngữ "người nghèo của DI" nghe có vẻ như là một điều xấu. Vì lý do đó, thuật ngữ "DI thuần túy" được khuyến khích ngày nay vì nó có vẻ tích cực hơn và thực sự mô tả chính xác hơn quá trình.

Không chỉ hoàn toàn tốt khi sử dụng DI của người nghèo / thuần túy để giới thiệu DI vào một ứng dụng hiện có, đây cũng là một cách sử dụng DI hợp lệ cho nhiều ứng dụng mới. Và như bạn nói, mọi người nên sử dụng DI thuần túy trên ít nhất một dự án để thực sự hiểu cách DI hoạt động, trước khi xử lý trách nhiệm đối với "phép thuật" của một container IoC.

Sự thay đổi của Paragidm trong các nhóm kế thừa / cơ sở mã là vô cùng rủi ro:

Bất cứ khi nào bạn đề xuất "cải tiến" cho mã kế thừa và có các lập trình viên "di sản" trong nhóm, bạn chỉ nói với mọi người rằng "họ đã làm sai" và bạn trở thành Kẻ thù trong suốt thời gian còn lại của họ với công ty.

Sử dụng DI Framework như một cái búa để đập vỡ tất cả các móng tay sẽ chỉ làm cho mã kế thừa trở nên tồi tệ hơn trong mọi trường hợp. Nó cũng cực kỳ rủi ro cá nhân.

Ngay cả trong những trường hợp hạn chế nhất như vậy, nó có thể được sử dụng trong các trường hợp thử nghiệm sẽ khiến cho các trường hợp thử nghiệm đó trở thành mã "không chuẩn" và "nước ngoài", tốt nhất sẽ chỉ bị đánh dấu @Ignorekhi chúng bị hỏng hoặc tệ hơn liên tục bị phàn nàn bởi Các lập trình viên kế thừa có nhiều đầu mối nhất với quản lý và được viết lại "chính xác" với tất cả "thời gian lãng phí cho các bài kiểm tra đơn vị" này chỉ đổ lỗi cho bạn.

Giới thiệu khuôn khổ DI, hoặc thậm chí là khái niệm "Pure DI" cho một dòng ứng dụng kinh doanh, ít hơn một cơ sở mã di sản khổng lồ mà không có sự quản lý, nhóm và đặc biệt là tài trợ của nhà phát triển chính sẽ là hồi chuông báo tử cho bạn về mặt xã hội và chính trị trong nhóm / công ty. Làm những việc như thế này là vô cùng rủi ro và có thể là tự sát chính trị theo cách tồi tệ nhất.

Dependency Injection là một giải pháp tìm kiếm một vấn đề.

Bất kỳ ngôn ngữ nào với các hàm tạo theo định nghĩa đều sử dụng phép nội suy phụ thuộc theo quy ước nếu bạn biết bạn đang làm gì và hiểu cách sử dụng đúng hàm tạo, đây chỉ là một thiết kế tốt.

Tiêm phụ thuộc chỉ hữu ích với liều lượng nhỏ cho một phạm vi rất hẹp:

• Những thứ thay đổi nhiều hoặc có nhiều triển khai thay thế bị ràng buộc tĩnh.

  • Trình điều khiển JDBC là một ví dụ hoàn hảo.
  • Các máy khách HTTP có thể thay đổi từ nền tảng này sang nền tảng khác.
  • Hệ thống đăng nhập thay đổi theo nền tảng.

• Các hệ thống plugin có các plugin có thể định cấu hình có thể được xác định trong mã cấu hình trong khung của bạn và được phát hiện tự động khi khởi động và được tải / tải lại động trong khi chương trình đang chạy.