Лучшие практики для архитектуры MVC [закрыто]

28

Мой вопрос больше о том, как создать приложение MVC. Например, нам рекомендуется использовать DI с шаблоном Repository для отделения доступа к данным от контроллера, однако очень мало говорится о том, КАК сделать это специально для MVC. Например, куда мы поместим классы репозитория? Похоже, они не связаны конкретно с моделью, поскольку модель также должна быть относительно отделена от реальных технологий доступа к данным.

Второй вопрос касается того, как структурировать слои или уровни. Кажется, что большинство примеров приложений (Nerd dinner, Music Store и т.

Если я хочу создать многоуровневое приложение / слой, каковы некоторые из лучших практик в отношении MVC?

asp.net-mvc architecture Эрик Фанкенбуш
источник

Ответы:

5

DI выполняется в ASP MVC с использованием фабрики контроллеров. Эта фабрика используется для разрешения зависимостей вашего контроллера.

MvcContrib имеет несколько реализаций Controller Facotry, которые вы можете использовать "из коробки". Я использую их реализацию Castle Windsor, и она работает хорошо. Также предложил бы проверить их TestHelper Class. Он имеет некоторые очень интересные функции для насмешки контроллера HTTPContext, сессий и т. Д. MVCContrib

Лично я хотел бы дать своим Моделям экземпляр Репозитория для работы. Модель предоставляет API для хранилища (CRUD). Зависимость контроллера от конкретной модели вводится при создании (конструкторе), который вводится через фабрику контроллеров. Это моя точка входа в граф объектов, которым управляет мой контейнер IoC.


источник
2

Например, куда мы поместим классы репозитория?

Они принадлежат модели; это модель в приложении.

Как мне структурировать слои? Если я хочу создать многоуровневое приложение / слой, каковы некоторые из лучших практик в отношении MVC?

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

Джордж Стокер
источник
То есть вы предлагаете, чтобы они включили в проект пользовательского интерфейса многоуровневое приложение?
Эрик Фанкенбуш
@Mystere Man Если это не гигантский, то они должны пойти в проект, который размещает ваше приложение MVC. В частности, бизнес-логика будет входить в контроллер, и каждое действие будет иметь свою собственную логику. MVC - это не просто шаблон интерфейса пользователя; поэтому я не согласен с вашим утверждением, что это «проект пользовательского интерфейса». Это не так. Это проект MVC, который как Viewраздел (это ваш пользовательский интерфейс).
Джордж Стокер
Хорошо, возможно я сформулировал это плохо. Однако вы не согласны с тем, что слой представления не должен манипулировать базой данных? И если вы поместите классы репозитория в модель, то представление может сделать это.
Эрик Фанкенбуш
в небольшом приложении MVC пользовательский интерфейс «Слой» - это просто папка, в которой хранятся представления. В более крупном приложении это может быть собственный проект. Если это собственный проект, он будет координироваться с контроллером, и контроллер может подключиться к BusinessLayer по мере необходимости. Никто за пределами контроллера даже не должен знать, что бизнес-уровень существует. Я думаю, вы автоматически думаете, что они в отдельных проектах, но они не должны быть.
Джордж Стокер