DAL → BLL <- GUI + составной корень. Как настроить DI-привязки?

Я сделал трехслойное приложение с refrences, как описано в этом :

DAL with Repositories -> BLL with services and IRepository <- Asp.net mvc-app

Чтобы запустить эту операцию с помощью инъекции зависимостей, я вижу несколько вариантов:
1. Добавьте ссылку на DAL из веб-приложения, чтобы иметь возможность устанавливать привязки при запуске приложения.
2. Используйте контейнер с xml-конфигурацией
(3. Используйте отражение, чтобы загрузить dal-assembly и найти типы)

Вариант 1. прост, а также позволяет скопировать DAL.dll в bin, но затем я неожиданно снова вернусь к ссылке, с которой я так старался избавиться. Теперь к хранилищам можно получить доступ напрямую. Варианты 2 и 3 кажутся излишне сложными.

Нет другого пути?

Ответы

Ответ 1

Ответ Mark Seemann дал мне идею для этого варианта:

DAL with Repositories -> BLL with services and IRepository <- Asp.net mvc-app
^------------------------^--------- Composition Root <-------´

Это означает, что вместо того, чтобы позволить веб-проекту ссылаться на DAL, он ссылается на отдельный корневой проект композиции, который ссылается как на DAL, так и на BLL. В состав-root-проект есть один класс с одним методом, который определяет привязки. Это дает следующие дополнительные преимущества:

Только три слоя. Четыре слоя будут жесткой продажей в команде.
Обеспечивается свободное соединение. Невозможно получить доступ к DAL из кода вида.
Улучшенная поддержка инструмента. Контроллеры остаются в стандартном расположении, поэтому "Add Controller" доступен в контекстном меню, а отсутствующие виды выделяются в коде контроллера. Также нет необходимости настраивать или писать пользовательский контроллер factory.

Я не вижу больших недостатков.

Ответ 2

Разбить приложение ASP.NET MVC на два:

Одна часть - ваше исходное приложение ASP.NET MVC, но без какой-либо логики. Просто сохраните Корень композиции и ваши представления (.aspx и т.д.) В этом проекте. Поскольку это корневой состав, вы можете иметь ссылки на все ваши другие проекты. Однако, поскольку вся логика была бы извлечена, теперь это Humble Object, так что хорошо иметь все ссылки на этом уровне.
Извлеките всю логику (контроллеры и т.д.) в проект Application Model, который будет просто обычным библиотечным проектом (DLL), который ссылается на двоичные файлы ASP.NET MVC. Этот проект должен будет ссылаться на BLL для доступа к интерфейсам, но это нормально. Тем не менее, как модель приложения, так и BLL эффективно защищены от DAL.

Результирующий слой будет выглядеть следующим образом:

Приложение ASP.NET MVC
Модель приложения
BLL
DAL

Ответ 3

Просто выберите вариант 1.

Просто потому, что у вас есть ссылка на сборку, это не значит, что вы нарушите SoC.

Веб-проект до сих пор ничего не знает о базовых реализациях, только интерфейс.

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

Ответ 4

Я разделил проект MVC двумя примерно так, как описано в ответе Mark Seemans.

MVCApplication - скромный объект и требует ссылок на все, но не имеет никакого кода MVC, кроме global.asax(который ему нужен) и web.config(который, по-видимому, хочет).

Проект MvcUI ссылается только на интерфейсы и использует инъекцию зависимостей.

Если вы поместите оба проекта (файлы .csproj) в один и тот же каталог, то папки Content, Controllers, Models, Scripts и Views находятся на одном месте, поэтому все инструменты работают.

На картинке ниже приведена идея.

Структура каталогов выглядит примерно так:

И вы получите граф зависимостей, подобный этому

Ответ 5

Недавно я следил за тем же и размышлял о MEF (Managed Extensibility Framework). С помощью MEF и рефлексии вы можете избавиться от этого DAL/единицы задания работы от вашего корня композиции, и вам не нужно иметь 2 mvc-проектов, как описано выше.