Обработка инъекций зависимостей - Куда идет логика?

Question

Я работаю на веб-сайте ASP.Net вместе со вспомогательной библиотекой классов для моей бизнес-логики, кода доступа к данным и т. Д.

Я КРАЙНЕ новичок и незнаком с Unity Framework и Dependency Injection в целом. Однако мне удалось заставить его работать, следуя исходному коду для начального набора портала ASP.NET 3.5 на codeplex. Но в этом и заключается проблема:

Библиотека классов настроена на Unity, и некоторые из моих классов имеют атрибуты [Dependency] в своих свойствах (для этого я использую исключительно установки свойств). Однако Global.asax сообщает Unity, как обрабатывать инъекции ... в библиотеке классов.

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

Я не уверен, насколько ясен вопрос. Пожалуйста, дайте мне знать, если мне нужно объяснить больше.

Answer 1

Лично я пытаюсь кодировать вещи, чтобы упростить контейнер IOC, но никогда не буду пытаться заставить контейнер IOC войти в проект.

Мое решение разбито примерно так: (Каждый из этих проектов).

• Project.Domain
• Project.Persistence.Implementation
• Project.Services.Implementation
• Project.DIInjectionRegistration
• Project.ASPNetMVCFrontEnd (я использую MVC, но это не имеет значения).

Я стараюсь поддерживать строгие границы в отношении ссылок на проекты. Фактический фронтенд-проект не может содержать никаких проектов * .Implementation напрямую. (В этом случае проекты * .implementation содержат фактические реализации интерфейсов в домене). Таким образом, ASPNetMVCFrontEnd содержит ссылки на домен и DIInjection, что угодно и на мой контейнер DI.

В Project.DIInjection, Что бы я ни связывал все части вместе. Таким образом, этот проект имеет все ссылки на реализации и структуру DI. Он содержит код, который выполняет регистрацию компонентов. Autofac позволяет мне легко регистрировать компоненты, поэтому я выбрал этот подход.

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

Answer 2

Несмотря на то, что не знаком с Unity (пользователь StructureMap), финальные отображения должны находиться в потребляющем приложении. Вы можете использовать dll, который вы используете, для определения этих отображений, но вы также хотите иметь возможность переопределять их при необходимости. Например, вам нужен экземпляр IFoo, и у вас есть один сопоставленный в вашей библиотеке классов, но вы добавили новый, который будет использоваться только на веб-сайте. Определив сопоставления, определенные на сайте, вы можете свободно связывать вещи, иначе вы используете контейнер DI?