Как смоделировать представление базы данных в ASP.NET MVC - PullRequest
0 голосов
/ 13 марта 2012

Мне нужно постепенно заменить ASP.NET Web Forms приложением на ASP.NET MVC3 многоуровневое приложение.Давайте рассмотрим только слой Repository .

В моем новом приложении MVC у меня есть один проект для Data (name MVC.Data)и один для Web .

В MVC.Data у меня есть edmx файл с классами EF, который моделирует только таблицу БД (без представлений), и класс Respository myRepository, который предоставляет методы, которые выполняютпростые запросы.

В старом приложении Web Forms у меня есть GridView, который заполняется с использованием DataSource базы данных SQL view.

Для того, чтобы получить тот же результатв моем новом приложении MVC3 у меня есть два варианта:

1) Создать Сервисный слой (и проект MVC.Services), где у меня есть метод, который заполняет новый класс myViewClassкоторый содержит все поля представления БД SQL и передает его контроллеру.

2) Создайте класс в проекте MVC.Data, который напрямую заполняется его конструктором, используя операторы LINQ непосредственно для классов EF.

Я читал о фабричном шаблоне , и первое решение кажется наиболее подходящим, однако многие люди всегда советуют не создавать Service Layer , если он не нужен,Какой лучший выбор в этом случае?

1 Ответ

1 голос
/ 13 марта 2012

На самом деле построение модели вида должно выполняться в слое отображения. В основном ваше действие контроллера может выглядеть так:

public ActionResult Index()
{
    SomeDomainModel model = repository.GetSomeDomainModel();
    SomeViewModel vm = Mapper.Map<SomeDomainModel, SomeViewModel>(model);
    return View(vm);
}

Модель представления определяется в проекте MVC, поскольку это класс, специально разработанный для удовлетворения требований данного представления.

Метод Mapper.Map<TSource, TDest>, который я показал в своем ответе, происходит от AutoMapper , который я использую в своем проекте, но вы можете определить любой пользовательский слой отображения, который вам нравится.

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

Что касается уровня обслуживания, вы можете использовать его, когда у вас есть несколько сложных бизнес-операций, которые могут состоять из нескольких простых вызовов репозитория. Но некоторые могут спорить о существовании сервисного уровня вообще. Я думаю, что оба подхода имеют свои плюсы и минусы, которые необходимо оценивать при проектировании системы, и, что наиболее важно, учитывать конкретный контекст и сценарий, который вы разрабатываете.

...