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

Question

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

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

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

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

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

Answer 1

Введение

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

что было бы хорошим соглашением на именование?

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

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

Мои герои ASP.NET MVC по этой теме: Jeffrey Palermo, Steve Smith и Jimmy Bogard.

Лук Архитектура

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

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

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

Стив Смит обсуждает Луковый Архитектура и подобные идеи с демонстрацией в MVC Solution Best Practices: A solution to the solution problem

Мое решение

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

• MyProject.Core
• MyProject.Domain
• MyProject.DependencyInjection
• MyProject.Infrastructure
• MyProject.Web
• MyProject.Tests

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

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

Уровень DependencyInjection содержит мой выбранный пакет DI/рамки и детали реализации. Я считаю его внешним слоем; аналогично UI или Infrastructure, и поэтому все в порядке, если он ссылается на многое. Для этого слоя необязательно быть отдельным проектом, и многие люди скажут вам, что вы этого не делаете. Ничего страшного; сделайте то, что работает для сложности вашего проекта. Мне нравится, что мой ДИ является его собственностью. Хорошая вещь об этом заключается в том, что я могу заменить рамки DI другой, и все будет хорошо. Никакие слои не ссылаются на проект DI.

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

Веб-сайт Уровень: это мой проект MVC и ссылки на Core.

Сложность и заключительные мысли

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

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

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

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