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

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

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

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

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

Другими словами, если это мое мнение:

@model MyApp.Models.CustomerModel

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

public ActionResult Index(CustomerModel model)

Или:

public ActionResult Index(CustomerEditModel model)

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

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

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

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

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

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

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

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

Также ASP.net MVC - одна ViewModel за просмотр или за действие?

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

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