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

Question

У меня есть ASP.NET MVC3 в C # и Razor.Архитектура приложения разделена на уровень доступа к данным (классы EF + репозиторий), уровень обслуживания, контроллер, ViewModels и View.

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

Предположим, у меня есть таблицы Product и ProductCategory, и на графике я должен отобразить процент проданных Products за ProductCategory за Месяц .По оси X у меня есть месяцы, по оси Y - процент ProductPerCategory / ProductTotal , и поэтому у меня столько строк, сколько и ProductCategories.

В этом случае мой Модель предметной области состоит из Product и ProductCategory объектов на EF .Мой репозиторий передает эти доменные объекты на его верхний уровень (уровень обслуживания).

Моя бизнес-модель создается объектом ProductGraph и моей службойСлой передает этот бизнес-объект своему верхнему уровню (Controller).

Мой контроллер берет этот ProductGraph объект и сопоставляет его с View Model ProductGraphViewModel для отображения вthe view.

Правильно ли это различие между моделями?Есть ли какой-либо недостаток или плохой подход к определению объектов, передаваемых между слоями?

Answer 1

Я отвечу на ваш вопрос, задав несколько своих.

1. В чем ваше различие между «моделью предметной области» и «бизнес-моделью»?Каждый из них дает большую / меньшую ценность, чем другой?Не зная больше, я бы предположил, что это одно и то же.

2. Какую выгоду дает ваш уровень обслуживания?Люди (включая меня) часто попадают в ловушку «Сервисный уровень», когда на самом деле это просто оболочка ваших методов репозитория.В итоге вы теряете специфику ORM в потребляющих слоях, в первую очередь побеждая точку вашей абстракции.

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

И да, @ sweaver2112 очень хорошо подходит для использования DI.Простая настройка, максимальная выгода.

Answer 2

Ну, у тебя большие пальцы руки у моего неспециалиста, это кажется довольно стандартным.Некоторые другие вещи, которые следует учитывать: 1) Интерфейс вашего DAL / Service Layer?и 2) вы используете внедрение зависимостей (передавая эти интерфейсы экземплярам контроллера)?Таким образом, вы можете легко переключаться между реализациями или проверять юнит-тесты.

Этот пост в блоге может представлять интерес.