Определение моделей представления для MVC / MVP - PullRequest
0 голосов
/ 02 марта 2010

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

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

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

Все со своими достоинствами и недостатками.

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

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

Ответы [ 3 ]

1 голос
/ 02 марта 2010

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

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


Модель:

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;}
}

Ведущий (я признаю - все еще не получил идею MVP полностью):

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

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

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 бросается в глаза.

0 голосов
/ 02 марта 2010

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

Почему три?

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

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

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

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

0 голосов
/ 02 марта 2010

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

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

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

...