Как организовать решение ASP.NET MVC (DDD)

Question

Я пытаюсь начать новый проект (asp.net MVC) и хотел бы применить некоторые правила DDD, которые я выучил за последние несколько месяцев.
Я не знаю, как организовать свое решение.
Я хотел бы использовать Nhibernate, но я не хочу использовать Fluent Nhibernate, потому что это должно быть что-то вроде эксперимента.
Я видел несколько примеров, когда люди держат все в одном проекте. Некоторые другие склонны создавать разные проекты для всего. Как вы думаете, я должен дифференцировать модель и хранилище или поместить его в один и тот же проект?
Если у кого-то есть ссылки на статьи и т. Д., Это будет оценено.

спасибо

Альберто

Answer 1

Джимми Богард (автор Automapper) написал превосходную статью о том, как он структурирует свой код, что может помочь в принятии вашего решения.

Я работал над проектами с тоннами отдельных сборок и проектов с небольшим количеством. Мое личное предпочтение - иметь меньше сборок, так как мне всегда легче работать. Если вы используете хорошие принципы кодирования (например, SOLID), тогда не должно иметь значения, используете ли вы 2 или 20 сборок.

Answer 2

Лично я считаю, что разделение каждого слоя на отдельный проект - лучшая идея.Есть определенные вещи, которых вы не можете достичь, имея 1 большой проект ASP.NET MVC, который включает все ваши слои.

Например, предположим, что у вас есть класс Product и ProductFactory .Вы хотите принудительно создать объект Product через ProductFactory .Для этого вы можете сделать конструктор из Product class внутренний .Таким образом, класс ProductFactory может создавать экземпляр класса Product , поскольку Product и ProductFactory находятся в одной сборке.Однако, если вы попытаетесь создать экземпляр класса Product из другого проекта (т.е. вашего проекта ASP.NET MVC), вы получите ошибку во время компиляции.Таким образом, вы можете добиться лучшей инкапсуляции.

Обратите внимание, что если Product , ProductFactory и ваш Controller находятся в одном проекте, вы все равно можете увидеть Product конструктор в вашем контроллере .Таким образом, разработчик-любитель, который не понимает архитектурных решений, лежащих в основе вашего дизайна, может просто игнорировать ProductFactory и напрямую создавать объект Product .

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

Answer 3

Зависит от того, насколько велик ваш проект, но я бы выбрал разные проекты для модели и хранилища. На мой взгляд, не стоит хранить вещи вашей модели в папке модели проекта WEB Mvc. Там слишком людно :) 1001 *

В DDD важно не вводить технологические элементы в логику вашего домена (например, NHibernate, который вы собираетесь использовать, или любой другой ORM, например). Обычно это происходит при создании так называемого антикоррупционного слоя.

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

Answer 4

MVC2 имеет концепцию областей, которые создают разделение интересов. Мне все еще не нравится, как это реализовано. Я создаю отдельный проект практически для каждого контроллера. Таким образом, я могу смешивать и сопоставлять контроллеры в новых проектах, над которыми я работаю. Отличный пример - у меня есть проект под названием «Безопасность», который обрабатывает все элементы входа и управления пользователями. Другой проект, который у меня есть, называется Notification, который обрабатывает все сообщения и электронные письма. Чтобы собрать их воедино, я создаю основной проект для любого проекта, над которым я работаю, а затем импортирую файлы DLL из другого проекта, и все, что мне нужно, это убедиться, что у меня есть представления и javascript, и это будет работа.