Dependency Inject (DI) "дружественная" библиотека

термин "инъекция зависимости" не имеет особого отношения к контейнеру IoC вообще, хотя вы, как правило, видите их вместе. Это просто означает, что вместо того, чтобы писать свой код так:

public class Service
{
    public Service()
    {
    }

    public void DoSomething()
    {
        SqlConnection connection = new SqlConnection("some connection string");
        WindowsIdentity identity = WindowsIdentity.GetCurrent();
        // Do something with connection and identity variables
    }
}

вы пишете это так:

public class Service
{
    public Service(IDbConnection connection, IIdentity identity)
    {
        this.Connection = connection;
        this.Identity = identity;
    }

    public void DoSomething()
    {
        // Do something with Connection and Identity properties
    }

    protected IDbConnection Connection { get; private set; }
    protected IIdentity Identity { get; private set; }
}

то есть, вы сделать две вещи, когда вы пишете свой код:

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

2. вместо того, чтобы создавать экземпляры этих интерфейсов внутри класса, передайте их в качестве аргументов конструктора (альтернативно, они могут быть назначены общедоступным свойствам; первый -конструктор инъекций, последний инъекции собственность).

ничто из этого не предполагает существования какой-либо библиотеки DI, и это действительно не делает код более сложным для написания без один.

если вы ищете пример этого, не смотрите дальше, чем сама платформа .NET Framework:

• List<T> осуществляет IList<T>. Если вы создаете свой класс для использования IList<T> (или IEnumerable<T>), вы можете воспользоваться такими понятиями, как lazy-loading, как Linq to SQL, Linq to Entities и NHibernate, которые все делают за кулисами, обычно через инъекцию свойств. Некоторые классы фреймворка фактически принимают IList<T> как аргумент конструктора, например BindingList<T>, который используется для нескольких функций привязки данных.

• Linq to SQL и EF построены полностью вокруг IDbConnection и связанные интерфейсы, которые могут быть переданы через открытые конструкторы. Однако вам не нужно их использовать; конструкторы по умолчанию отлично работают со строкой подключения, находящейся где-то в файле конфигурации.

• если вы когда-либо работали над компонентами WinForms, вы имеете дело с "услугами", например INameCreationService или IExtenderProviderService. Вы даже не знаете, что такое конкретные классы are. .NET на самом деле имеет свой собственный контейнер IoC, IContainer, который привыкает к этому, и Component класс GetService метод, который является фактическим служба поиска. Конечно, ничто не мешает вам использовать любой или все эти интерфейсы без IContainer или этот конкретный локатор. Сами услуги только слабо связаны с контейнером.

• контракты в WCF построены полностью вокруг интерфейсов. Фактический конкретный класс обслуживания обычно упоминается по имени в файле конфигурации, который по существу является DI. Многие люди не понимают этого, но вполне возможно поменять эту систему конфигурации с другим контейнером IoC. Возможно, более интересно, что поведение службы-это все экземпляры IServiceBehavior который может быть добавлен позже. Опять же, вы можете легко подключить это в контейнер IoC и выбрать соответствующее поведение, но функция полностью пригодна для использования без одного.

и так далее и так далее. Вы найдете DI повсюду в .NET, просто обычно это делается так легко, что вы даже не думаете об этом как о DI.

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

редактировать 2015: прошло время, теперь я понимаю, что все это было огромной ошибкой. Контейнеры IoC ужасны, и DI-очень плохой способ справиться с побочными эффектами. Фактически, все ответы здесь (и сам вопрос) следует избегать. Просто осознайте побочные эффекты, отделите их от чистого кода, и все остальное либо встанет на свои места, либо станет неуместным и ненужным усложнением.

оригинальный ответ следующее:

---

У меня был чтобы столкнуться с этим же решением при разработке SolrNet. Я начал с того, чтобы быть Ди-дружественным и агностическим контейнером, но по мере того, как я добавлял все больше и больше внутренних компонентов, внутренние фабрики быстро становились неуправляемыми, и полученная библиотека была негибкой.

Я закончил тем, что написал свой собственный очень простой встроенный контейнер IoC в то же время обеспечивая Виндзор объекта и модуль Ninject. Интеграция библиотека с другими контейнерами-это просто вопрос правильной проводки компонентов, поэтому я мог бы легко интегрировать ее с Autofac, Unity, StructureMap, что угодно.

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

подробнее в этом блог пост.

для MassTransit кажется, полагаться на что-то подобное. Он имеет IObjectBuilder интерфейс, который действительно является IServiceLocator от CommonServiceLocator с несколькими другими методами, затем он реализует это для каждого контейнера, т. е. NinjectObjectBuilder и обычный модуль/объект, т. е. MassTransitModule. Тогда это полагается на IObjectBuilder создать то, что ему нужно. Это действительно так подход, конечно, но лично мне это не очень нравится, так как он на самом деле слишком много проходит вокруг контейнера, используя его в качестве локатора службы.

монорельс осуществляет свой собственный контейнер а также, который реализует старый добрый IServiceProvider. Этот контейнер используется во всей этой структуре через интерфейс, который предоставляет известный сервис. Чтобы получить бетонный контейнер, он имеет встроенный локатор поставщика услуг. Элемент Виндзор объекта указывает этот локатор поставщика услуг на Windsor, что делает его выбранным поставщиком услуг.

итог: нет идеального решения. Как и любое дизайнерское решение, этот вопрос требует баланса между гибкостью, ремонтопригодностью и удобством.

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

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

разрешение пользователям библиотеки подключать свои собственные рамки DI кажется мне немного неправильным, поскольку это значительно увеличивает объем обслуживания. Это также становится более плагинов среды, чем прямой DI.