Преимущества использования FormViewModel в контроллерах по сравнению с классом частичной модели в моделях

Question

Мне сложно понять два подхода к дизайну с точки зрения долговременной расширяемости в моем текущем приложении ASP.NET MVC.

ORM, который я использую для предоставления данных, - Linq2SQL. Который только изумительный для работы с, BTW!

Теперь у меня возникли проблемы с дизайном классов модели для моих просмотров. В настоящее время у меня есть partial class для каждого объекта в базе данных.

• Такой подход позволяет мне расширить класс без необходимости переключения strongly typed модели на моих взглядах
• можно легко добавить дополнительные свойства для дополнительных данных (в основном меты)
• можно легко добавить вспомогательные методы, которые заполнить списки для меня и/или делать другие транзакции
• Одна проблемы остается:
  • Я не могу создать пользовательский constructor, как это уже управляемый Linq2SQL

После прочтения ASP.NET MVC Book и некоторые уроки, я вижу, очень распространенное использование FormViewModels для предоставления дополнительных данных об объекте.

В настоящее время мне очень нравится дизайн partial class для моих сущностей. Но я бы не прочь переделать дизайн, поскольку я все еще создаю приложение.

Каковы преимущества FormViewModel вместо легкого partial class подхода и каковы лучшие практики в этом вопросе?

Вся помощь более чем ценится!

Answer 1

Как и во многих вещах, все зависит. Если ваше приложение мало, и у вас есть отношения «один к одному» между тем, что видит пользователь, вам могут не потребоваться модели просмотра. Вы можете напрямую разоблачить свои модели. Большинство приложений - это небольшие приложения.

По мере того как ваше приложение, в частности, ваш пользовательский интерфейс, растет, вы можете обнаружить, что вам требуется большее разделение между объектом модели уровня данных и объектом модели уровня представления. Вот и появляются модели просмотра. Хотя свойства одинаковы (то есть пользователь имеет имя FirstName, LastName, EmailAddress и т. Д.), Методы и требования моделей разные. Просмотр моделей позволит вам более пристально следить за Single Responsibility Principle.

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

Answer 2

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

Использование viewmodels - очень распространенный шаблон, и было доказано, что он работает очень хорошо. Однако существуют разные способы использования этого шаблона. Вы можете использовать пространственные модели, которые содержат объекты модели домена. Или вы можете создавать полностью отдельные модели просмотра, содержащие только данные, которые они должны отображать, и ни одна из ваших моделей домена. Если вы используете этот подход, вы получите много кода отображения. Здесь я бы посоветовал вам использовать automapper, который вам очень поможет.