Какой метод внедрения зависимостей я должен использовать в dotnet?

Question

[Редакция 14.05.09: Мне нужно это для таргетинга на Dotnet 2.0 из-за моего сценария развертывания]

Я впервые в Dependency Injection & IoC.

Я вижу, что существует множество контейнеров и библиотек, которые могут помочь процессу.

Каковы плюсы и минусы использования этих библиотек. Какой ваш любимый (dotnet) контейнер и почему?

А как насчет того, чтобы прокатить свой собственный контейнер для инъекций зависимости?

Спасибо

Питер Стивенс

Answer 1

Если вам нужен только Dependency Injection, вероятно, AutoFac будет лучшим вариантом, поскольку он небольшой, довольно простой и логичный. Это не должно быть трудно грохнуть.

Как только вы это получите, и почувствуете необходимость в более зрелом продукте (который может делать другие вещи, чем просто DI), я бы посоветовал взглянуть на Castle Windsor, довольно мощный из коробки, очень хорошо разработанный и настраиваемый. Если вам это не нравится, я слышал хорошие новости о StrcutureMap.

Answer 2

Spring.Net

Answer 3

Нашел другую тему по этой теме здесь

Answer 4

После еще одного исследования: Ninject представляется полезной альтернативой. И это поддерживает Dotnet 2.0. И это не требует массивной конфигурации XML.

Все еще пытаюсь найти лучшие практики для использования другой конфигурации DI для сред производства и модульного тестирования.

Answer 5

Я использую инструмент IOC, который называется StructureMap: Структура карты Я нашел этот инструмент очень полезным и простым в реализации.

Answer 6

Spring.NET. Если вы хотите использовать только DI-компонент Spring, это все, что вам нужно (и вам нужно только ссылаться на эти библиотеки DLL). Позже, если вы захотите использовать модуль модульного тестирования, Quartz или NHibernate, вы также можете добавить эти DLL - они построены модульно. И у всех разных частей есть согласованность, потому что они из одной структуры. Я думаю, что это действительно хорошая структура, которая очень хорошо дополняет .NET.

Answer 7

Вы можете использовать Common Service Locator в своем коде, где он должен явно вызывать контейнер. Таким образом, если вы недовольны выбранным фреймворком, вы можете переключить его, подключив новый.

Answer 8

Мне нравится MEF , главным образом потому, что он будет очень хорошо поддерживаться в .NET 4.0 (так как MS объявила, что использует его в качестве основы DI в Visual Studio 2010). *

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

Это работает и для IoC, но это не является его основной целью.