различия между контейнерами IoC

Question

Я ищу руководство по выбору контейнера IoC для приложения ASP.NET MVC.

В чем различия между (например) StructureMap, Ninject, Castle Windsor, Unity, autofac и другими? Кто-нибудь может дать какие-нибудь советы или ссылки на ресурсы, которые могут помочь выбрать одну библиотеку?

Обновление : есть один вопрос ( Корпоративная библиотека Unity против других контейнеров IoC ), который говорит о различиях в инициализации контейнеров IoC.

Но есть ли различия в функциональности, которые сделали бы некоторые контейнеры IoC лучшим выбором для приложения ASP.NET MVC?

Answer 1

Одна вещь, которая отличается между различными контейнерами IoC - это режимы жизненного цикла или создания экземпляров, которые поддерживаются «из коробки» (когда создавать новый экземпляр компонента):

• StructureMap
  • переходный процесс (называемый на запрос), одиночный, локальный для потока, на HttpContext, на HttpSession, гибридный
• Ninject
  • переходный процесс, синглтон, на поток, на запрос HttpRequest
• Замок Виндзор
  • singleton, переходный процесс, на поток, объединенный, на HttpRequest (дополнительные доступны через средства)
• autofac
  • переходный (заводской), синглтон, по запросу HttpRequest
• Единство
  • переходный процесс, синглтон, на поток

Answer 2

Вот полезное сообщение в блоге , в котором сравниваются функции различных платформ IOC, доступных в .Net, но я не знаю, что есть что-то о MVC, которое бы отдавало предпочтение одному контейнеру над другим.

Max

Answer 3

Я лично остановился на Autofac. Одна вещь, которая кажется действительно хорошей, - это детерминированное распоряжение ресурсами.

Это и оно имело интеграцию с ASP.Net, когда я это проверил. Я должен посмотреть на другие фреймворки некоторое время, но у меня не было проблем с этим. Сообщения об ошибках, которые он выдает, когда есть неразрешимый компонент, действительно хороши.

Лучше всего попробовать проекты с каждым из них. Я стал настоящим поклонником создания конфигураций в коде (насколько это возможно) и использования конфигураций XML в качестве резервной копии. Поэтому создайте свой собственный список приоритетов и попробуйте их.

Answer 4

Лично - это то, где ООП перестает быть правильным решением, потому что он плохо обрабатывает IoC. Поиск собственного решения может быть лучше. Лично я бросаю свой собственный с F # - до тех пор, пока я могу контролировать оба конца.

Новый Rx может помочь в решении некоторых из этих проблем, но все же он просто заимствует бэндайд из функционального программирования.

Я полагаю, что какое-то время мы застряли с объектами в качестве базовой модели - к счастью, объекты веб-сервисов работали настолько плохо, что стандарты уже отошли от них к функциональным интерфейсам, таким как SOAP.