Модели с ограниченным доступом для MVC/MVP

Question

Короткий вопрос - как вы определяете свои модели просмотра?

Вот некоторые из вариантов:

1. Pass фактической модели в поле зрения.
2. Создайте модель с ссылкой на модель (например Model.Product)
3. Создайте модель просмотра с необходимыми свойствами модели и установите их в модели.
4. Вероятно, намного больше.

Все с их собственными преимуществами и недостатками.

Каков ваш опыт - хорошо и плохо? И используете ли вы ту же модель для GET/POST?

Спасибо за ваш ввод!

Answer 1

В принципе - это все о разделении обязанностей.

Больше вы их разделяете - более многословное, сложное, но понятное для понимания.

---

Модель:

public class foo{ 
    string Name{get;set} 
    Bar Bar {get;set;} 
    string SomethingThatIsUneccessaryInViews {get;set;} 
} 

public class bar{ 
    string Name {get;set;} 
} 

public class fizz{ 
    string Name{get;set;} 
} 

Presenter (я признаю, - до сих пор не получил идею MVP полностью):

public someSpecificViewPresenter{ 
    fizz fizz{get;set;} 
    foo foo{get;set;} 
    necessaryThingsForWhatever[] necessaryThingsForWhatever{get;set;} 
    public void someLogicIfNeeded(){...}   
} 

магии отображение object2object & уплощение, ViewModel modelmetadata конфигурации идет здесь ...

ViewModel (NB => POCOS с реквизитами контейнера. Нет логики не должна идти здесь.):

public class fooViewModel{ 
    string Name {get;set;} 
    string BarName {get;set;} 
} 

public class fizzViewModel{ 
    string Name {get;set;} 
} 

public class someSpecificView{ 
    fooViewModel foo {get;set;} 
    fizzViewModel fizz {get;set;} 
    whateverViewModel whatever {get;set;} 
} 

и здесь идет "дас счастливый конец" ...

<use viewdata="someSpecificView m" /> 

<p> 
Our foo:<br/> 
${Html.DisplayFor(x=>x.foo)} 
</p> 

<p> 
Our fizz:<br/> 
${Html.DisplayFor(x=>x.fizz)} 
</p> 

${Html.UberPaging(m.whatever.Paging)} 

И да, я использую ту же модель для GET/POST. См. this для получения дополнительной информации о том, почему/ifs.

---

Но в последнее время - я ищу другие решения. CQRS buzz поймал мой взгляд.

Answer 2

В моих проектах это действительно смесь.

Если я хочу отобразить форму с деталями Customer X, я просто передаю объект DAL Customer на мой взгляд. На самом деле бесполезно создавать отдельный ViewModel для него, отображать все его свойства и отображать их. Это пустая трата времени imho.

Иногда, хотя модели немного сложнее. Они являются результатом нескольких запросов, содержат некоторые дополнительные данные, поэтому в этих случаях я создаю пользовательский ViewModel и добавляю необходимые данные из своей модели к нему. В вашем случае это будет вариант 2, или иногда 3. Я предпочитаю, чтобы за прохождение моей модели и добавление дополнительных 10 элементов в мои ViewData.

Answer 3

Я захватил T4 шаблоны из SubSonic 3. Они были изменены, и я добавил несколько новых. Я могу запустить один из них, и он генерирует 3 отдельные модели просмотра для каждой таблицы. Затем я могу изменить по мере необходимости.

Почему три?

1. FormModel - содержит данные, необходимые для отображения в виде для редактирования или создания. Внешние ключи преобразуются в SelectLists. Поле DateTime делится на компоненты даты и времени.

2. PostModel - это объект, возвращенный из Почты формы. DropDownLists публикуются как Int или эквивалентный тип. В модели только необходимые члены.

3. DisplayModel - используется для немедленного отображения данных.

Я всегда создавал их в подпапках под названием Generated. Когда я отжимаю их, я перемещаю их в папку «Модели». Он не полностью автоматизирует процесс, но он генерирует много кода, который в противном случае я мог бы создать вручную.