У меня есть 3-уровневое приложение службы .NET, которое следует стандартному подходу:
Frontend -> Object Model / Business Logic -> Data Access
Я пытаюсь узнать о внедрении зависимостей по пути, и до сих пор нашел это отличным (используя Autofac). Каждый из 3-х уровней должен создавать ассортимент объектов, иногда с дополнительной конфигурацией / и т.д. Кажется, что контейнер DI должен быть идеальным решением для этого, но у меня есть некоторые проблемы с просмотром, где он должен жить по отношению к остальной части системы.
В настоящее время у меня есть класс во внешнем интерфейсе, который настраивает контейнер DI. В основном это большой набор кода, говорящий container.Register<SomeType>() и так далее.
Проблема в том, что он конфигурирует контейнер для всех трех уровней и, следовательно, должен иметь достаточно инвазивные знания об уровне доступа к данным. Наличие кода в моем интерфейсе с такими знаниями вызывает тревожные сигналы в моей голове, так как смысл разделения приложения на уровни состоит в том, чтобы избежать именно такой ситуации.
Это также усугубляется тем фактом, что мой уровень доступа к данным не просто представляет собой SQL-сервер, представляющий собой пустую корзину битов, но состоит из множества сложных COM-взаимодействий и вызовов P / Invoke, что довольно сильно влияет на DI. конфигурации.
Я подумал о том, чтобы разбить его - возможно, иметь один контейнер на уровень или иметь класс «Setup» на каждом уровне, который обращается к глобальному контейнеру DI, чтобы зарегистрировать его собственные биты, но я не уверен, что это вызовет больше проблем, чем решит ...
Я был бы очень признателен, если бы кто-нибудь мог поделиться своим опытом использования DI с многоуровневыми приложениями.
Спасибо, Орион.