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

Я размышляю над дизайном библиотеки C #, которая будет иметь несколько различных функций высокого уровня. Конечно, эти функции высокого уровня будут реализованы с использованиемSOLID принципы дизайна класса как можно больше. Таким образом, вероятно, будут классы, предназначенные для непосредственного использования потребителями на регулярной основе, и «поддерживающие классы», которые являются зависимостями этих более распространенных классов «конечного пользователя».

Вопрос в том, как лучше спроектировать библиотеку, чтобы она была такой:

DI Agnostic - Хотя добавление базовой «поддержки» для одной или двух общих библиотек DI (StructureMap, Ninject и т. Д.) Кажется разумным, я хочу, чтобы потребители могли использовать библиотеку с любой структурой DI.Можно использовать без DI. Если пользователь библиотеки не использует DI, библиотека должна быть максимально простой в использовании, что сокращает объем работы, которую пользователь должен выполнить для создания всех этих «неважных» зависимостей, просто чтобы добраться до «настоящие» классы, которые они хотят использовать.

В настоящее время я думаю о том, чтобы предоставить несколько «модулей регистрации DI» для общих библиотек DI (например, реестр StructureMap, модуль Ninject), а также набор или классы Factory, которые не являются DI и содержат связь с этими несколькими фабриками.

Мысли?

Ответы на вопрос(4)

Ваш ответ на вопрос