7

Tôi đang cố giới thiệu phương pháp lập trình DI/IoC vào nhóm phát triển của chúng tôi, nhưng một trong những nhà phát triển đã hỏi câu hỏi sau:Trợ giúp nhận DI/IoC trong nhà

Tại sao chúng ta cần? Có ví dụ cụ thể nào có thể cho tôi thấy lợi ích của việc sử dụng khung DI/IoC như lâu đài windsor không?

Vì vậy, tôi hỏi nếu có bất kỳ nghiên cứu điển hình hoặc bài viết nào có chứng minh DI/IoC có thể được hưởng lợi trong một trang web cấp doanh nghiệp .NET không?

Cảm ơn trước

Cập nhật: Tôi nhận thức của tất cả các lợi ích của DI/IoC mang lại, nhưng tôi chưa thấy một ví dụ hoàn chỉnh trên web mà đi qua một toàn bộ quá trình của việc tạo ra một ứng dụng sử dụng DI/IoC và hưởng lợi từ nó. Một lần nữa, bất kỳ bài viết hoặc liên kết nào sẽ được đánh giá cao.

+3

Tôi sẽ cảnh giác với tư cách nhà phát triển đó nếu bạn đang cố gắng giới thiệu một phương pháp lập trình cho dự án của tôi và không thể trả lời câu hỏi đó. – JoshJordan

+0

Đồng ý với Josh, nếu nó có vẻ & trông giống như dầu rắn, có lẽ là ... (trừ khi tôi cố gắng dạy TDD cho đội, LOL) – dferraro

Trả lời

6

tôi đang làm việc trên một dự án mà tôi có thể thấy ít nhất ba lợi ích cho Dependency Injection và Inversion of Control:

  1. Sự linh hoạt DI, và ở một mức độ thấp hơn, IoC cho phép vì nó gắn liền với kiểm tra đơn vị. Chúng tôi có thể không ở trên một khía cạnh cụ thể của mã (hoặc hệ thống đang thử nghiệm) và kiểm tra bit chức năng này mà không cần phải chuẩn bị một bảng cơ sở dữ liệu hoặc phải tuân thủ các phần của mã chúng tôi không quan tâm tại thời điểm này.

  2. Tiêm phụ thuộc qua IoC là một điều hoàn toàn liền mạch, tự động và cho phép mọi người làm việc trên logic mà không yêu cầu các lớp hỗ trợ cơ bản hoàn tất. Ví dụ, tôi có thể viết một trang web hiển thị danh sách người dùng mà không cần phải viết bất kỳ mã nào để lấy thông tin đó từ cơ sở dữ liệu. Điều đó có thể được viết bởi người khác, có thể song song, vì vậy nhiều công việc hơn có thể được thực hiện trong thời gian ngắn hơn.

  3. Trên một trong các dự án hiện tại của tôi, tôi muốn có khả năng giới thiệu giao diện người dùng web và xử lý mặt sau cho một trong các bên liên quan. Điều này được thực hiện dễ dàng hơn nhiều bởi DI và IoC bởi vì tôi có thể có một bộ sưu tập hàng giả cung cấp dữ liệu chính xác mà tôi cần để thực hiện bản trình diễn. Bằng cách này, tôi không freaking ra ngày hôm trước với việc đảm bảo các bảng cơ sở dữ liệu được dân cư theo cách tôi mong đợi họ được.

DI khuyến khích một khớp nối lỏng lẻo giữa một lớp cụ thể và phụ thuộc của nó, trong khi IoC cho phép chúng tôi định cấu hình khả năng triển khai những phụ thuộc này vào các lớp sử dụng chúng. Cái sau rất quan trọng đối với # 3, vì ứng dụng web của tôi sẽ được cấu hình nhiều nhất với IoC dựa trên các thiết lập mà tôi đã tạo cho tệp web.config. Tôi sẽ cần phải thay đổi chỉ tập tin đó khi chúng tôi đi vào sản xuất và bắt đầu sử dụng các lớp không giả mạo.

6

Để đặt tên cho vài lợi ích cụ thể:

  • Cleaner mã, mang bản chất của logic kinh doanh của bạn ở trong đó, không phải là độ dày cơ sở hạ tầng
  • DI cho phép bạn tạo ra nhiều ứng dụng mô-đun bằng cách cung cấp một cơ chế để tách các lớp ứng dụng của bạn
  • IoC cho phép bên ngoài việc đấu dây/khởi động ứng dụng và cung cấp quản lý tài nguyên tập trung (ở mức độ nào đó).Hàm ý - bạn có nhiều thời gian để tập trung vào logic chức năng/kinh doanh thực tế

Một số thông tin tốt về IoC và DI có thể được đọc ở đây: http://www.theserverside.com/tt/articles/article.tss?l=IntrotoSpring25

Cấp đó là về Spring Framework, khái niệm DI chung vẫn áp dụng .