ASP.NET MVC с уровнем обслуживания и уровнем репозитория, где следует определить интерфейсы?

Question

Я нахожусь в процессе определения довольно простой многоуровневой архитектуры для приложения .NET MVC, которое имеет уровень репозитория и уровень обслуживания.Я нашел несколько довольно ясных и простых примеров, в частности www.asp.net, а также несколько вопросов и ответов здесь, но я ищу что-то более простое, подходящее для небольших приложений, но использующее разные проекты, чтобы донести идею.В примере, на который я ссылался выше, репозиторий и сервис представлены как классы в пространстве имен Models.Этого просто недостаточно для четкого разделения, чтобы я мог его правильно проиллюстрировать.

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

Вопрос в том, где мне определить IRepository и IService?Разумеется, и проект службы, и проект репозитория должны ссылаться на них.Тогда кажется очевидным, что они должны быть определены в другом проекте, на который ссылаются как проекты службы, так и проекты репозитория.Если да, то каким будет хорошее соглашение об именах?Что-то вроде XXXXContracts?

Аналогично, для моделей данных, передаваемых между уровнями представления, сервиса и хранилища, приемлемо ли иметь отдельный проект под названием XXXXModels, на который ссылаются все уровни?Я понимаю, что в некоторых случаях модели, передаваемые между уровнем сервиса и репозитория, могут отличаться от моделей, передаваемых между уровнем сервиса и уровнем представления, но принцип тот же.

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

Answer 1

Введение

Это то, о чем я тоже спрашивал себя.У меня всегда есть один животрепещущий вопрос, похожий на ваш;

каким будет хорошее соглашение об именах?

Как мне называть вещи?Должны ли они храниться в папках или проектах?

После поиска я подозреваю, что ответ таков: это действительно не имеет значения.Важно, чтобы ваше решение имело разумную архитектуру и чтобы вы старались следовать передовым практикам, таким как ТВЕРДЫЙ.

Мои герои ASP.NET MVC по этой теме: Джеффри Палермо, Стив Смит и Джимми Богард.

Луковая архитектура

Джеффри Палермо обсуждает комбинацию старых идей, но объединяет их и дает визуально стимулирующее название Луковая архитектура (рекомендуется к прочтению).Джеффри демонстрирует хороший подход к проблеме, куда положить вещи.Он объясняет, что в центре (или вверху) вашего приложения находится Основной.На этом уровне вы должны разместить такие интерфейсы, как IRepository и IService.

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

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

Стив Смит обсуждает луковую архитектуру и подобные идеи с демонстрациями в Лучшие практики решения MVC:Решение проблемы решения

Мое решение

В моих решениях MVC у меня есть типичная структура:

• МойПроект.Core
• МойПроект.Домен
• MyProject.DependencyInjection
• МойПроект.Инфраструктура
• МойПроект.Веб
• МойПроект.Тесты

А Основной содержит мои интерфейсы.Обычно он разделен на такие папки, как «Сервисы», «Модели», «Домен», «Репозитории» и т. д.

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

А Внедрение зависимости Уровень содержит выбранный мною пакет/инфраструктуру DI и детали реализации.Я считаю это внешним слоем;похоже на пользовательский интерфейс или инфраструктуру, поэтому ничего страшного, если он много ссылается.Этот слой не обязательно должен быть отдельным проектом, и многие люди советуют вам не делать этого.Это нормально;делайте то, что подходит для сложности вашего проекта.Мне нравится, чтобы мой DI был самостоятельным.В том, что это так отдельно, хорошо то, что я могу заменить инфраструктуру DI на другую, и все будет в порядке.Никакие слои не ссылаются на проект DI.

А Инфраструктура Уровень содержит информацию о регистрации, отправке по электронной почте и доступе к данным.Он будет содержать мой ОРМ выбора.Это не бизнес-логика и не пользовательский интерфейс.Это мой путь решения задач.Он находится на внешнем слое, но ссылается только на Ядро.

А Интернет Layer — это мой проект MVC, и он ссылается только на Core.

Сложность и последние мысли

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

Это хороший момент.Важно помнить о сложности вашей проблемы.Но пусть вас не смущают хорошие практики решения.Мое решение и луковая архитектура не обязательно очень сложны и не сильно раздувают ваше решение.Они просто держат вещи отдельно.

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

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