Размещение класса модуля Autofac в решении - PullRequest
Новая
       76

Размещение класса модуля Autofac в решении

0 голосов
/ 18 декабря 2018

Я читал много примеров кода для DI и autofac.Одна вещь, которую я заметил, состояла в том, что многие люди объединяют интерфейсы и реализации в одном проекте.С точки зрения дизайна, я считаю, что это не правильно, и все интерфейсы должны быть в отдельной сборке.Поэтому я определяю свои проекты следующим образом:

UI - Web App/Windows App/Both - Views - Models - Controllers/ ViewModels Business - Services/Processes - Interfaces - Model DataAccess - Repositories & UoW - Interfaces - Model

Таким образом, мои бизнес-сервисы ссылаются только на интерфейсы и модели DataAccess, но остаются независимыми от фактической реализации.Аналогичным образом, пользовательский интерфейс также относится только к бизнес-интерфейсам и моделям, и существует четкое разделение.Это также помогает мне в тестировании, где я могу самостоятельно протестировать слой.

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

  1. Как мне обрабатывать эту цепочку зависимостей в модулях?
  2. Где разместить классы модулей и как при запуске программы обнаружить все модули самым простым способом?

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

  1. , поскольку проекты, ссылающиеся на интерфейсы, не знают о реализациях, я не могу написать какие-либо конкретные привязки в вызывающей сборке, такой как корневая сборка пользовательского интерфейса.
  2. Некоторые источники говорято чистоте сборок от любых реализаций DI и наличии отдельных сборок для модулей.Это хороший подход для всех типов приложений?(Например, корпоративное LOB-приложение или веб-приложение и настольное приложение ISV, распространяемое среди множества независимых пользователей)

1 Ответ

0 голосов
/ 19 декабря 2018

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

Возвращаясь к вашему вопросу: в конце концов, ваш исполняемый проект (веб-приложение или приложение для Windows) должен знать как об интерфейсах, так и о реализациях.
Мое мнение заключается в том, что модули Autofac должны находиться в проекте верхнего уровня, поэтому в нем должны быть ссылки на все необходимые проекты.Моя причина в том, что в дополнение к определению регистраций сервисов вы также определяете срок жизни для каждой из них.Это понятие зависит от проекта, который использует ваши зависимости;В веб-проекте некоторые службы могут быть зарегистрированы на HTTP-запрос, а приложения Windows могут иметь различный срок службы.

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

...