Написание библиотеки с включенным внедрением зависимостей

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

Prism - плохой пример, поскольку последний раз, который я использовал (2 года назад), он требовал, чтобы объекты были DI-агностическими, принудительно применяя атрибута [Injection]. Хорошим примером, не зависящим от DI, является Spring Framework (чрезвычайно популярная платформа DI для Java, имеет порт .NET под названием Spring.NET), который позволяет включать DI через так называемый < strong> файлы контекста - это файлы xml, описывающие зависимости. Последний не обязательно должен быть частью вашей библиотеки, оставив его как полностью независимый файл dll.

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

Это не означает, что любая структура DI должна поддерживать манипуляции с простыми объектами CLR (.NET), также известными как POCO-ы. Некоторые фреймворки полагаются только на свои конкретные механизмы и могут не подходить для использования с DI-независимым кодом. Обычно они требуют прямой зависимости от структуры DI для библиотеки, чего, я думаю, вы хотите (и, вероятно, должны) избегать.

Это немного спорно, но я предлагаю использовать «Укол бедняка». Я не говорю, что это здорово, но у него есть несколько допустимых вариантов использования (например, Service Locator) с некоторыми ограничениями. Это потребует немного большего обслуживания, но это избавит вас от зависимости от другой библиотеки для регистрации контейнера IoC. Вам следует прочитать статью Марка Симанна по этой теме.

Я недавно реализовал этот подход в моей очень простой библиотеке. По сути, вы пишете два конструктора для общедоступных классов библиотеки.

internal SitemapProvider(IActionResultFactory actionResultFactory, IBaseUrlProvider baseUrlProvider)
{
    _actionResultFactory = actionResultFactory;
    _baseUrlProvider = baseUrlProvider;
}

public SitemapProvider() : this(new ActionResultFactory(), new BaseUrlProvider()) { }

Как видите, только второй конструктор является общедоступным, и вы сами заполняете зависимости. Это также обеспечивает инкапсуляцию на уровне сборки. Вы все еще можете протестировать этот класс, добавив InternalsVisibleTo сборки и свободно используйте внедрение зависимостей в свою библиотеку. Пользователь также может создавать экземпляры с новым ключевым словом или добавлять интерфейс этого класса в свою регистрацию IoC.

Я не знаю, есть ли в .NET широко распространенная библиотека регистрации контейнеров IoC. Я сам думал написать такой, но у каждого контейнера есть свои уникальные особенности, и с жизненными циклами объектов все усложняется. Также людям будет неловко полагаться на другую библиотеку для этого.

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

Для работы внедрения зависимостей вам не нужны фреймворки IoC.

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

Скорее всего, они захотят реализовать свои собственные версии некоторых интерфейсов.

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