Настройка проекта MVC на уровне предприятия. Что ожидается?

Question

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

Я ищу советы о том, как профессионалы делают это на уровне предприятия.

Я вижу разные школы, хотя об этом, некоторые люди разрабатывают по-настоящему способ N-уровня, другие предпочитают использовать EF Code First непосредственно в приложении MVC и имеют модели FAT и имеют одно большое приложение MVC с логическое разделение проблем и т. д.

Итак, для проекта среднего размера это моя настройка, и я хочу попросить ваше мнение об этом.

MVC приложение

Модель - Здесь мои модели имеют только то, что нужно просматривать, логика проверки и т.д. Эти модели предназначены для передачи данных между контроллером и только видом.

Контроллеры. Вызовите сервисный уровень, в котором живет бизнес-логика, и при необходимости вернет модели домена. Преобразует модели домена в модели просмотра и наоборот.

Сервис слой

Это были бизнес (домен) логика жизни. Сервисный уровень также отвечает за связь с уровнем данных для выполнения операций CRUD. Сервисный уровень возвращает модели домена контроллеру в приложении MVC, а также ожидает, что модели домена будут вызваны.

хранилища данных слоя

Уровень данных представляет собой тонкую оболочку вокруг EF и выполняет операции CRUD. обычно у меня будет подход Code First, в котором модели объектов для меня создаются EF. Я конвертирую первые модели кода EF в модели домена и возвращаю их на сервисный уровень. Слой данных также ожидают модели домена со служебного уровня, которые, в свою очередь, конвертируют в первые модели кода EF и сохраняются в БД.

домена Модель слой

Эти модели предметной области, которые используются и общие кап приложений слоев.

Какой лучший дизайн? Что ожидается на уровне предприятия?

Answer 1

Нет ничего особенного в том, что вы применили подход. Однако я считаю это слишком сложным. Уровень вашего репозитория, в частности, является абсолютно ненужным уровнем абстракции. Вы можете просто просто свернуть EF-материал в свой сервисный слой и называть его днем. Нужно преобразовать объект в модель домена, а затем в модель представления, откровенно говоря, боль. Просто сопоставьте свою сущность с вашей моделью просмотра и обратно.

Единственное, что вы действительно должны иметь в виду, это то, что ASP.NET MVC очень свободно следует шаблону MVC. Нет такой вещи, как настоящий MVC Model, и попытка заставить что-то вроде класса сущности в эту форму - огромная ошибка.Ваша Модель представляет собой комбинацию и взаимодействие вашего класса сущности, модели представления, которые представляют этот класс, и логику запросов, которую вы убираете в своем сервисном слое.

Answer 2

Я хотел бы, чтобы предложить эти слои в проекте ----

Entites Layer-- она должна содержать только все Poco классы в модели folder.Nothing еще

Уровень данных ---- Он должен содержать логику взаимодействия Db. Также должен присутствовать ваш класс Dbcontext. Вы можете использовать шаблон хранилища и единицу рабочего шаблона для лучшего разделения беспокойства. Используйте инъекцию зависимостей для разрешения зависимостей с помощью контейнера Unity (имеется много других контейнеров). Пожалуйста, посмотрите на этот шаблон дизайна и контейнер. статьи, доступные в сети для этого. Пройдите их тщательно.

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

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

Его довольно большой вопрос. Надеюсь, у вас есть идея от этого.