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

Question

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

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

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

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

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

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

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

Вся помощь приветствуется!

Answer 1

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

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

Answer 2

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

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

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