Castle Windsor là gì và tại sao tôi phải quan tâm?

Tôi là một nhà phát triển Windows lâu năm, đã cắt răng trên win32 và COM sớm. Tôi đã làm việc với .NET từ năm 2001, vì vậy tôi khá thành thạo C # và CLR. Tôi chưa bao giờ nghe nói về Castle Windsor cho đến khi tôi bắt đầu tham gia Stack Overflow. Tôi đã đọc hướng dẫn "Bắt đầu" của Castle Windsor, nhưng nó không nhấp.

Dạy cho chú chó già này những mánh khóe mới và cho tôi biết lý do tại sao tôi nên tích hợp Castle Windsor vào các ứng dụng doanh nghiệp của mình.

Castle Windsor là một công cụ điều khiển đảo ngược. Có những người khác thích nó.

Nó có thể cung cấp cho bạn các đối tượng với các phụ thuộc được xây dựng sẵn và có sẵn ngay trong đó. Toàn bộ biểu đồ đối tượng được tạo thông qua sự phản chiếu và cấu hình thay vì toán tử "mới".

Bắt đầu tại đây: http://tech.groups.yahoo.com/group/altdotnet/message/10434

Hãy tưởng tượng bạn có một lớp gửi email. Người gửi email. Hãy tưởng tượng bạn có một lớp WorkflowStepper khác. Bên trong WorkflowStepper bạn cần sử dụng EmailSender.

Bạn luôn có thể nói new EmailSender().Send(emailMessage);

nhưng điều đó - việc sử dụng new- tạo ra một TIGHT COUPLING khó thay đổi. (đây là một ví dụ nhỏ

Vậy điều gì sẽ xảy ra nếu, thay vì làm mới cậu bé hư hỏng này trong WorkflowStepper, bạn chỉ cần chuyển nó vào hàm tạo?

Vì vậy, bất cứ ai gọi nó đều phải đăng ký EmailSender.

new WorkflowStepper(emailSender).Step()

Hãy tưởng tượng bạn có hàng trăm lớp nhỏ này chỉ có một trách nhiệm (google SRP) .. và bạn sử dụng một vài trong số chúng trong WorkflowStepper:

new WorkflowStepper(emailSender, alertRegistry, databaseConnection).Step()

Hãy tưởng tượng không lo lắng về các chi tiết EmailSenderkhi bạn đang viết WorkflowStepperhoặcAlertRegistry

Bạn chỉ lo lắng về mối quan tâm bạn đang làm việc.

Tưởng tượng toàn bộ biểu đồ (cây) của các đối tượng và phụ thuộc này được nối dây vào RUN TIME, để khi bạn thực hiện việc này:

WorkflowStepper stepper = Container.Get<WorkflowStepper>();

bạn có được một thỏa thuận thực sự WorkflowSteppervới tất cả các phụ thuộc được điền tự động vào nơi bạn cần chúng.

Không có new

Nó chỉ xảy ra - bởi vì nó biết những gì cần những gì.

Và bạn có thể viết ít lỗi hơn với mã DRY được thiết kế tốt hơn theo cách có thể kiểm tra và lặp lại.

Mark Seemann đã viết và cuốn sách tuyệt vời về DI (Dependency Injection) là một tập hợp con của IOC. Ông cũng so sánh một số container. Tôi không thể khuyên bạn nên cuốn sách này đủ. Tên cuốn sách là: "Dependency Injection in .Net" https://www.manning.com/books/dependency-injection-in-dot-net

Tôi nghĩ IoC là một bước đệm đi đúng hướng trên con đường hướng tới năng suất cao hơn và hưởng thụ đội ngũ phát triển (bao gồm PM, BA an BOs). Nó giúp thiết lập một sự tách biệt mối quan tâm giữa các nhà phát triển và để thử nghiệm. Nó mang lại sự an tâm khi kiến ​​trúc cho phép linh hoạt vì các khung có thể ra vào.

Cách tốt nhất để hoàn thành mục tiêu mà IoC (CW hoặc Ninject, v.v.) đưa ra là loại bỏ chính trị # 1 và # 2 cần loại bỏ các nhà phát triển để đưa ra sự hiểu biết sai lầm khi phát triển. Có phải hai giải pháp này dường như không liên quan đến IoC? Họ đang :)

Castle Windsor Dependency Injection container.có nghĩa là với sự trợ giúp của điều này, bạn có thể tiêm phụ thuộc của mình và sử dụng chúng mà không cần tạo chúng với sự trợ giúp của từ khóa mới. ví dụ: Hãy xem xét bạn đã viết một kho lưu trữ hoặc một dịch vụ và bạn muốn sử dụng nó ở nhiều nơi, trước tiên bạn cần đăng ký dịch vụ / kho lưu trữ của mình và bạn có thể bắt đầu sử dụng nó sau khi tiêm vào nơi cần thiết. Bạn có thể xem hướng dẫn dưới đây mà tôi đã làm theo để tìm hiểu lâu đài gió.

liên kết .

Hy vọng nó sẽ giúp bạn.

Đơn giản thôi. Hãy tưởng tượng bạn có một số lớp được chôn trong mã của bạn cần một vài giá trị cấu hình đơn giản để thực hiện công việc của nó. Điều đó có nghĩa là mọi thứ tạo ra một thể hiện của lớp đó cần có được các phụ thuộc đó, vì vậy bạn thường phải cấu trúc lại vô số các lớp trên đường để chuyển một chút cấu hình xuống nơi mà cá thể được tạo.

Vì vậy, rất nhiều lớp bị thay đổi một cách không cần thiết, bạn gộp các giá trị cấu hình thành một lớp cấu hình lớn cũng xấu ... hoặc tệ nhất vẫn là Trình định vị dịch vụ!

IoC cho phép lớp của bạn có được tất cả các khoản phụ thuộc mà không gặp rắc rối đó và cũng quản lý vòng đời của các trường hợp rõ ràng hơn.