Что плохого в привязке вашего View к свойству модели, а не к ViewModel? - PullRequest
2 голосов
/ 21 апреля 2010

Я часто слышу, что Модель должна быть обернута Моделью Представления, что Представление не связано с Моделью / не знает об этом.

С MVC принято связывать вид с моделью ... никто не жалуется и что?

Я боюсь создавать все эти обёртки и делать почти только дублирующиеся свойства.

Ответы [ 8 ]

6 голосов
/ 21 апреля 2010

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

Но ваша модель должна отражать домен структура и логика, в то время как модель представления отражает структуру и логику UI .По крайней мере, насколько я понял.Эти два не обязательно одинаковы, и каждый может меняться независимо от другого.

2 голосов
/ 21 апреля 2010

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

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

2 голосов
/ 21 апреля 2010

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

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

Безопаснее использовать ViewModel.

2 голосов
/ 21 апреля 2010

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

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

1 голос
/ 22 апреля 2010

Существует без проблем привязка напрямую к модели из вашего представления , где это возможно .

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

Если вы никогда не хотите испортить свои Модель с помощью Просмотр проблем, у вас не останется иного выбора, кроме как создать ViewModel .

1 голос
/ 22 апреля 2010

Один из распространенных сценариев, когда ViewModels очень удобен, - это когда Enum values ​​ должны отображаться. На мой взгляд, ViewModel является идеальным местом для преобразования значений Enum в удобные для пользователя представления. Вы даже можете ввести шаг локализации в вашей ViewModel.

Кроме того, ViewModels может упростить некоторые другие сценарии. Однако, как вы сказали, они также могут дублировать много кода. Тем не менее, вы можете создать ViewModel со свойством Model, которое позволяет связывать напрямую со свойствами класса Model. Теперь, если позже вы поймете, что вам нужен какой-то шаг преобразования, вы все равно можете добавить это свойство в ViewModel и связать его с этим свойством.

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

0 голосов
/ 23 апреля 2010

Вы могли бы также спросить: «Что плохого в том, чтобы объединить все функции моей программы в один гигантский класс?» С одной стороны, в этом нет ничего плохого; это можно заставить работать. С другой стороны, все не так: если ваша программа представляет собой один большой шарик проволоки, вы должны исправить все это, чтобы изменить что-либо из этого.

Посмотрите на программиста Windows Forms, написанного новичком. Вы найдете всю бизнес-логику в кнопках обработчиков событий Click. Что в этом плохого? Разве вы не хотите, чтобы эта логика выполнялась, когда пользователь нажимает кнопку?

По сути, это то, что вы предлагаете делать в мире WPF. Это будет работать? Конечно. Для тривиальных проектов это может даже работать хорошо. Однако вы накапливаете технический долг, и когда придет время, вам придется его погасить, превратив код в нечто управляемое.

0 голосов
/ 22 апреля 2010

Это зависит от индикаторов май: например, если ваша модель предоставлена ​​EF, нет смысла показывать ее вашему представлению - зачем, черт возьми, представлению нужны все методы / свойства модели и тонны вещей (не говоря уже о безопасности данных)если ваша модель действительно проста и вы чувствуете, что не собираетесь ее расширять / изменять с помощью ВМ, то нет ничего, что могло бы использовать ее просто так:)

...