2010-04-08 4 views
3

Как я понимаю, модели домена - это классы, которые описывают только данные (совокупные корни). Это POCOs и не ссылаются на внешние библиотеки (ничего особенного).ASP.NET MVC: какой механик возвращает объекты ViewModel?

Просмотреть модели, с другой стороны, являются классами, которые содержат объекты модели домена, а также все специфичные для интерфейса объекты, такие как SelectList. Модель ViewModel включает using System.Web.Mvc;.

Репозиторий извлекает данные из базы данных и передает их нам через объекты модели домена. Какой механик или устройство создает объекты модели представления, заполняя их из базы данных? Будет ли это завод, имеющий доступ к базе данных? Не могли бы вы отобразить определенные типы, например System.Web.Mvc, в репозиторий? Что-то другое?

Например, если у вас есть выпадающий список городов, вы ссылаетесь на объекте SelectList в корневом каталоге вашего объекта View Model, прямо рядом с вашей ссылкой DomainModel:

public class CustomerForm { 
    public CustomerAddress address {get;set;} 
    public SelectList cities {get;set;} 
} 

Город должен прийти из базы данных и быть в виде объекта списка выбора. Надеемся, что вы не создадите специальный метод репозитория для извлечения только отдельных городов, а затем создадите резервный второй объект SelectList, чтобы иметь нужные типы данных.

ответ

2

AutoMapper может быть использован для конвертирования ваших моделей в другие модели. Вот очень nice article, как вы могли бы использовать его в своем приложении ASP.NET MVC.

В основном ваше действие контроллера может выглядеть следующим образом:

[AutoMap(typeof(ProductModel), typeof(ProductViewModel))] 
public ActionResult Index(int id) 
{ 
    return View(_repository.GetById(id)); 
} 

Таким образом, вы по-прежнему работать с моделями доменов в контроллере и фильтр AutoMap действия будет использовать AutoMapper для преобразования модели в представлении-модель в соответствии с файл сопоставления и передать его в представление.

+0

Когда вы обрабатываете дополнительные данные, например, заполняет список выпадающих списков, вы извлекаете эти данные из репозитория? Вы создаете специальные модели домена для обработки этих «микро» моделей домена, таких как «Список городов»? Или есть какой-то другой шаблон, например, Factory, у которого есть доступ к db? –

+1

Я нашел отличную запись об этом Стив Микелотти: http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx –

3

Я бы сказал, что заполнение модели представления от объекта домена является ответственностью Контроллера. Действие «Get» контроллера будет извлекать объект домена из репозитория, создать модель представления, заполнить модель представления и передать ее в представление.

+0

+1 - контроллер «представляет» вид с правой модели данных для связывания (ViewModel) –

+0

Так вы создаете Repository методы извлечения выпадающего списка опций, а затем создать код в контроллере, чтобы превратить его в ViewModel? Вероятно, вы бы реорганизовали код в контроллере в качестве отдельных методов, чтобы поддерживать низкий уровень ответственности, поэтому у вас будет куча методов, висящих там где-то в пространстве контроллера, а не на том, чтобы какой-нибудь механик разместил их все? Как получить доступ к базе данных для заполнения этих ViewModels? У вас действительно есть тонна методов репозитория, по одному для каждого DDL, которые возвращают эти объекты микродомена, и больше для их преобразования? –

+0

Уместно иметь эту функциональность в пространстве контроллера. Если у вас много похожих выпадающих списков, тогда может возникнуть некоторая возможность реорганизовать его, чтобы объединить их в один репозиторий. Затем, чтобы создать модели просмотра, вы все равно можете сгруппировать код, используя фабрику или какие-то карты. Преобразование объектов домена для просмотра моделей, безусловно, является одной из проблем для приложений MVC. Я обнаружил, что сгруппировать классы сопоставления вместе могут помочь. – Mac

4

Я предлагаю вам ознакомиться с CQRS (разделением ответственности за запрос команд). Основываясь на этом шаблоне, вам действительно не нужно получать свою модель из репозитория, а затем сопоставлять ее с ViewModel.

Вы можете выделить отдельный набор классов для извлечения данных (запросов) и отображения в представлении. Вы можете позвонить этим классам Провайдерам или тому, что вам нравится. Эти классы могут возвращать объекты ViewModel или общие объекты DataSet/DataTable. В этом подходе есть 2 преимущества:

1- Вам не нужно беспокоиться о сопоставлении между Model и ViewModel, следовательно, проще кодировать и обслуживать. 2- Много раз свойства вашей модели не совсем то, что пользователь ожидает увидеть на экране. Некоторые разработчики добавляют новые свойства к своей модели только для целей отображения, что заставляет модель терять свою реальность в долгосрочной перспективе. Вернув ViewModel или DataSet/DataTable прямо из вашего Провайдера, не завися от вашей модели, вы позволяете вашей модели и вашим ViewModels развиваться отдельно.

Мош

Смежные вопросы