В MVC3 я должен иметь отдельные модели «редактирования» и модели «отображения»?

Question

С MVC3 я должен проектировать свои модели представления так, чтобы одна была привязана к представлению (DisplayModel), а другая была отправлена ​​обратно в контроллер (EditModel)?

Чтобы уточнить, яя не спрашиваю о моделях данных по сравнению с моделями представлений - я знаю, что не стоит связывать мои представления / контроллеры с моделями данных / предметной области.

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

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

Другими словами, если это мой взгляд:

@model MyApp.Models.CustomerModel

Должно ли мое действие контроллера выглядеть так:

public ActionResult Index(CustomerModel model)

Или:

public ActionResult Index(CustomerEditModel model)

В какой-то момент мы делали последнее (отдельно).Но в последнее время мы начали делать первый (общий).

Причиной этого изменения было то, что:

1. С ненавязчивой проверкой MVC3, если я используюDataAnnotations в моей модели для проверки, это необходимо в обеих моделях, если они разделены (в модели отображения для сопоставления проверки на стороне клиента и в модели редактирования для проверки на стороне сервера).

2. По мере развития нашего приложения мы поняли, что наши модели отображения и редактирования были идентичны на 95%, за исключением списков выбора, которые были в наших моделях представления.Теперь мы переместили их в общий класс и передаем их через представление.

Но я видел некоторые другие обсуждения, которые указывают на наличиеобщие модели для view / controller - плохая идея, и что нарушает разделение интересов.

Может кто-нибудь помочь мне понять компромиссы для этих двух подходов?

Answer 1

Я видел очень хорошие аргументы за и против, все зависит от того, что лучше всего подходит для вашего приложения. Не существует единого подходящего для всех подхода!

Если вы еще не читали его, Джимми Богард написал очень хороший пост о том, как его команда делает MVC здесь , который охватывает эту тему.

Answer 2

Я согласен с ответом rich.okelly , что нет правильного подхода.

Однако при использовании одной модели у меня есть пара проблем.

Будет очень полезно всегда использовать одну модель без лишних свойств, когда в представлении должен отображаться выбираемый список объектов. Модель должна иметь список объектов, а также свойство для принятия значения POST, выбранного пользователем. Эти ненужные свойства добавляют небольшое количество беспорядка кода и накладных расходов. (Одним из способов решения этой проблемы является наличие в модели только выбранного идентификатора и использование помощников HTML для создания списков.)

Еще одна проблема связана с безопасностью. Распространенным сценарием является отображение информации в форме, которую следует рассматривать только для чтения. В случае ViewModel и EditModel EditModel будет содержать только свойства, которые, как ожидается, будут POSTed, тогда как ViewModel будет содержать все свойства. Например, если форма отображает зарплату пользователя, пользователь сможет выставить «зарплату» и привязать ее к свойству Salary ViewModel автоматически с помощью MVC. На этом этапе необходимо что-то , чтобы убедиться, что оно не попадет в базу данных. Это может быть логика if / else, атрибут Bind, логика Automapper или что-то еще, но дело в том, что это шаг, который можно пропустить. При рассмотрении срока службы приложения мне нравится четкость модели редактирования с течением времени.

Эти проблемы не означают, что две модели хороши, а одна модель плоха, но их следует учитывать при выборе дизайна.

Answer 3

Я думаю, вы поймете, что он ударил или пропустил, независимо от того, каким путем вы идете, но если вы можете пойти по пути простоты обслуживания, то вы должны это сделать. По моему опыту, поддерживать одну модель гораздо проще, очевидно, но, похоже, всегда есть какое-то деловое решение, которое заставляет меня разделить модели. Если вы на 95%, то я думаю, что вы в хорошей форме. Ваше приложение с точки зрения удобства обслуживания, связанного с вашими моделями, будет легко обслуживать. Когда происходит изменение, у вас есть одно место, чтобы сделать это изменение, по большей части. Проблема, с которой я всегда сталкиваюсь, - это масштабирование бизнес-изменений по нескольким моделям. Проблемы с копированием / вставкой или просто забытие о каком-либо свойстве где-то всегда причиняет мне боль из-за проблемы с несколькими моделями.

Answer 4

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

Answer 5

Нет - одна модель просмотра для обоих направлений.За этим не только трудно следить, но и можно легко ввести недопустимые значения в страницу, которые затем будут автоматически связаны.Я мог бы перезаписать ваш custommerid (или создать его), например.

Наследовать от модели базового представления, если вы должны или не полагаетесь на аннотации данных вообще и используете свободный api для сохранения вашей модели.

Отличная ссылка (несколько несвязанная, но автокарта хороша)

edit (извините, кто-то ранее опубликовал это ниже, я только что понял) http://lostechies.com/jimmybogard/2009/06/30/how-we-do-mvc-view-models/

Также ASP.net MVC - одна ViewModel для View или per Action?

Вы (IMHO) должны обычно связываться с вашим VieWModel для конкретного метода, а не с моделью общего представления.Вы можете оказаться в ловушке пропущенных свойств и т. Д., Но это также может отлично сработать для вас.

Используйте auto mapper для перехода между ними.Джимми также имеет хороший атрибут AutoMap при возвращении в представление.Возвращаясь к другому пути, я бы не стал использовать CustomerModel в целом, так как там могут быть поля, обязательные для заполнения, например, с точки зрения создания.Например, идентификатор клиента может быть обязательным полем, а для действия «создать» его не будет.Но - если вы обнаружите, что в большинстве случаев это действительно работает для вас, то нет никаких причин не использовать его.

Answer 6

мы поняли, что наши модели отображения и редактирования были идентичны на 95%, за исключением списков выбора, которые были в наших моделях представления.Теперь мы переместили их в общий класс и передаем их через представление.

Они на 95% идентичны в данных и операциях или только в данных?Помните, что классы инкапсулируют данные и поведение.

Если они на 95% похожи по свойствам, но имеют совершенно разные операции, вам может быть полезно разделить их на два класса.Или вы можете этого не делать :)

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