Как я должен проектировать библиотеку классов, чтобы учесть IoC, но не зависеть от конкретного контейнера

Question

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

В частности, эта библиотека содержит контроллеры ASP.NET MVC, которые зависят от различных сервисных интерфейсов. Я понимаю, что могу создать IoCControllerFactory, но я не уверен, что это лучший подход, поскольку некоторые пользователи могут не иметь возможности или не хотят использовать это в своих приложениях только для того, чтобы получить функциональность, предоставляемую моей библиотекой.

Answer 1

Передайте свойство в конструктор для простых сценариев.

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

CommonServiceLocator - это такой интерфейс.

---

Редактировать:

Я бы предложил другой дизайн, который бы сделал CommonServiceLocator бесполезным и улучшил бы общее восприятие пользователей вашей библиотеки:

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

Затем необходимо указать две основные точки расширения: Конфигурация - способ обеспечить пользовательскую реализацию зависимостей (например, Logger ...) Фабрики - если вашей библиотеке требуется создать экземпляр объекта пользователя, предоставьте способ указать фабрику, чтобы ваши пользователи могли его подключить. Таким образом, они могут использовать свой собственный контейнер для создания и внедрения своих объектов.

Я сделал два полных поста в блоге об этом дизайне:

Контейнер IOC, Go Hide

Контейнер МОК, Go Hider (часть 2)

Answer 2

Если количество зависимостей довольно мало, вы можете просто передать их через конструктор. Таким образом, ваши потребители имеют полный выбор, как построить ваши объекты.

Свойства / сеттеры или пользовательские объекты инициализации являются альтернативными возможностями и охватывают другие области спектра проектирования.