Ninject vs Unity cho DI [đóng]


104

Chúng tôi đang sử dụng ASP.net MVC.

Cái nào trong số này là bộ khung DI tốt nhất Ninject hoặc Unity và tại sao?


94
NInject tốt hơn vì bạn có thể mua nam châm có thương hiệu thú vị từ trang web của họ.
Ivan G.

5
Phiên bản cập nhật của câu hỏi này (anyway rất giống nhau) mà một số người có thể tìm thấy hữu ích: stackoverflow.com/questions/4581791/...
Jason Xuống

Câu trả lời:


46

Lần trước khi xem xét một trong số chúng, tôi thấy Ninject tốt hơn một chút. Nhưng cả hai đều có mặt hạn chế của họ.

Ninject có một sơ đồ cấu hình thông thạo hơn. Sự thống nhất dường như chủ yếu dựa vào cấu hình XML. Hạn chế chính của Ninject là nó yêu cầu bạn tham chiếu Ninject.Core ở khắp mọi nơi trong mã của bạn để thêm thuộc tính [Inject].

Nếu tôi có thể hỏi, tại sao bạn lại giới hạn lựa chọn của mình cho hai điều này? Tôi nghĩ Castle.Windsor, Autofac và StructureMap ít nhất là tốt hoặc tốt hơn.


47
Bạn chỉ cần sử dụng thuộc tính Inject nếu có nhiều hơn một hàm tạo và bạn cần cho Ninject biết phương thức khởi tạo nào sẽ sử dụng. Theo mặc định, nó sử dụng hàm tạo có nhiều tham số nhất.
Jeffrey Cameron

11
Đồng thời, cũng có một phần mở rộng Ninject.Web.Mvc chính thức. Bạn thay đổi MvcApplication của mình để dẫn xuất từ ​​NinjectHttpApplication, quay Kernel trong đó và gọi RegisterAllControllersIn (Assembly.GetExecutingAssembly ()) để nó quản lý tất cả các bộ điều khiển trong assembly đã cho. Ma thuật.
Michael Stum

18
Câu trả lời này bây giờ khá không liên quan với reagrd cho Ninject 2. Trong khi khiếu nại là hợp pháp cho Ninject 1, Ninject 2 cho phép một người làm việc mà không xả rác ở đó các lớp có thuộc tính. ninject2 sẽ hoạt động minh bạch mà không cần phải sửa đổi các lớp của bạn.
chillitom

3
Tương tự đối với sự thống nhất vì nó dường như hoàn toàn có thể định cấu hình thông qua mã tại thời điểm này (v3.0.1304.1)
Eric

46

Tôi biết đây là một câu hỏi cũ, nhưng đây là suy nghĩ của tôi:

Cá nhân tôi thích Ninject. Tôi thích các giao diện thông thạo và tránh sử dụng XML. Tôi thường thích XML, chỉ không dành cho loại công cụ cấu hình này. Đặc biệt khi có sự tham gia của việc tái cấu trúc, các giao diện thông thạo sẽ giúp bạn dễ dàng sửa hơn.

Tôi bỏ lỡ ObjectFactory của StructureMap, nhưng có nhiều cách giải quyết dễ dàng để thêm nó vào Ninject.

Như Jeffery đã chỉ ra rằng bạn không cần phải sử dụng thuộc tính [Inject] khi bạn chỉ có một hàm tạo.

Tôi nhận thấy rằng tôi thích các giao diện thông thạo không chỉ vì chúng tránh được XML mà còn vì chúng gây ra lỗi thời gian biên dịch khi tôi thay đổi thứ gì đó ảnh hưởng đến chúng. Cấu hình XML không và tôi càng ít phải nhớ thay đổi thì càng tốt.


10

Ninject phát hiện các phụ thuộc vòng tròn nếu bạn sử dụng Injection Constructors trái ngược với Unity mà không phụ thuộc vào kỹ thuật tiêm chỉ ném ra một StackOverflowException rất khó gỡ lỗi.


9

Tôi đồng ý với Mendelt, không có khung DI "tốt nhất". Nó chỉ phụ thuộc vào tình huống và tất cả chúng đều có ưu và khuyết điểm. David Hayden nói trên DotNet Rocks rằng Unity là lựa chọn ưu tiên nếu bạn sử dụng phần còn lại của EntLib và đã quen với điều đó. Cá nhân tôi sử dụng Unity vì khách hàng của tôi thích thực tế là nó cho biết Thư viện Doanh nghiệp của Microsoft (Unity) trên các tệp DLL, nếu bạn hiểu những gì tôi đang nói.

Tôi sử dụng cả cấu hình xml để thiết lập giao diện và triển khai cụ thể của chúng nhưng sau đó tôi sử dụng các thuộc tính trong mã khi chèn, như:

<type type="ILogger" mapTo="EntLibLogger">
   <lifetime type="singleton"/>
</type>

và trong mã:

[InjectionConstructor]
public Repository([Dependency] ILogger logger)

Cá nhân tôi nghĩ rằng điều đó làm cho nó rõ ràng hơn những gì sẽ xảy ra, nhưng tất nhiên người ta có thể tranh luận rằng bạn sẽ có tham chiếu đến sự thống nhất trên toàn bộ ứng dụng của mình. Tuỳ bạn.


Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.