StructureMap DI по сборке модели

Question

Я новичок в внедрении зависимостей и у меня возник вопрос / требуется руководство.

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

С тех пор я разбил свою модель (включая логику хранилища) на собственную сборку и добавил уровень обслуживания. В интересах DI класс сервисного уровня берет IRepository в своем конструкторе. Это кажется мне неправильным, поскольку теперь все потребители моей модели должны знать о хранилище (по крайней мере, сконфигурируйте свой DI, чтобы знать, какой использовать). Я чувствую, что это входит в кишку модели.

Что с этим не так?

Answer 1

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

Разрешая потребителей службы через контейнер, потребители должны указывать только свою зависимость от службы, а не какие-либо зависимости, которые могут понадобиться службе. Поэтому потребители услуги не будут связаны с ее зависимостями (например, с вашим хранилищем). Это преимущество внедрения зависимостей через контейнер, а не ручного внедрения зависимостей.

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

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

Если вы предполагаете, что все клиенты будут использовать определенный контейнер (например, StructureMap), то вы можете упростить требования регистрации, предоставив реестры, которые инкапсулируют все конкретные потребности регистрации для клиента.

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

Answer 2

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

Я написал этот пост в блоге специально о NHiberante, но если вы посмотрите на шаблон репозитория во внедрении, вы можете легко изменить специальный код NH для использования вашего резервного хранилища.

Создание общий универсальный и расширяемый репозиторий NHiberate