Вопрос по asp.net-mvc, service-layer, repository-pattern – ASP.NET MVC с уровнем обслуживания и уровнем хранилища, где должны быть определены интерфейсы?

16

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

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

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

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

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

Ваш Ответ

1   ответ
53

Вступление

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

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

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

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

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

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

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

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

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

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

Мое решение

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

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

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

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

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

инфраструктура слой содержит информацию о регистрации, электронной почте и доступе к данным. Это будет содержать мойORM выбора. Это'не бизнес-логика, и этоне вещи UI. Это'железная дорога моего решения, чтобы добиться цели. Это's на внешнем слое, но он ссылается только на ядро.

Web Слой - это мой проект MVC, и он ссылается только на ядро.

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

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

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

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

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

Хороший ответ. Как вы можете войти в свои контроллеры, если веб-слои ссылаются только на ядро? А как насчет других помощников, которые являются кросс-проектами? Где вы их храните? systempuntoout
Хороший ответ, именно то, что я искал для создания нового веб-приложения. Shane Van Wyk
@systempuntoout попробуйте изучить концепции АОП и перехвата. Это даст вам идеи относительно сквозных проблем. Ant Radha
+1 за лук. Пример:ludwigstuyck.wordpress.com/2013/03/05/... L-Four
Я удивлен, что этот ответ не имеет больше голосов. Очень хорошо написано и интересно! sebbzzz

Похожие вопросы