3-уровневая архитектура MVC 4 Project

Question

Я работаю над веб-приложением, используя ASP.Net MVC 4 3-уровневую архитектуру, и я застрял в определенных точках. Я знаю, что здесь существуют похожие темы, но ни один из них не был достаточно ясным. Я уже создал необходимые слои, которые представляют собой UI (проект MVC4), BLL-Business Logic Layer (класс библиотеки), BOL-Business Object Layer (класс библиотеки, который содержит ADO.net) и DAL-Data Access Layer (класс библиотеки). зависимости слой следующим образом:

• UI зависит от БОЛА и УСКА
• BLL зависит от БОЛА и DAL
• DAL зависит от BOL

Я хочу, чтобы вы поправьте меня, если я неправильно в следующем. BOL является основным эталонным уровнем, который обменивает необработанные записи dB с DAL, а затем отправляет их в BLL, который отвечает за любые логические вычисления, затем получает обновленные записи и отправляет их контроллеру в пользовательском интерфейсе.

Зная выше,

1. Где мы должны поместить функции CRUD?
2. Где и почему мы должны создавать класс для объявления (плюс набор и получение) полезных полей базы данных?
3. Что именно следует помещать в папку ViewModel; другими словами, поскольку мы уже определили переменные на предыдущем шаге и в Entity, добавляет ли он какое-либо значение для сохранения папки Model?

Благодарим вас заранее.

Answer 1

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

1. Где мы должны поместить функции CRUD? CRUD - частый шаблон на разных уровнях. Hi-level Репозиторий предлагает аналогичные методы, как низкоуровневый Стол шлюза.

2. Где и почему мы должны создавать класс для объявления (плюс набор и получение) полезных полей базы данных? Эти классы обычно простые Объекты передачи данных (DTO) или немного сложнее Активные записи. В соответствии с Dependency Inversion Principle интерфейс для этих классов должен обеспечивать уровень бизнес-логики, а реализация должна обеспечивать уровень доступа к данным. Поскольку DTO - очень простые классы, они могут предоставляться «как есть» без разделения интерфейса/реализации.

3. Что именно следует помещать в папку ViewModel; другими словами, поскольку мы уже определили переменные на предыдущем шаге и в Entity, добавляет ли он какое-либо значение для сохранения папки Model? В теории сущности должны быть нашими моделями; но на практике это часто бывает не так. F.E. в ASP.NET MVC модели должны обеспечивать не только значение раскрывающегося поля, но и все возможные значения; поэтому для этого требуется отдельный класс модели.

Результатом может быть то, что у вас есть три или четыре очень похожих класса на разных уровнях приложения. Конечно, это не очень хорошо, поэтому Аспектное программирование может применяться в этом случае.