Программисты WPF / Silverlight: MVVM - это перебор?

Question

У меня просто смешанные чувства к MVVM. Кажется, мне нужно так много кода, чтобы заставить работать самые корректные вещи. Я скучаю по событиям (командование - такая боль), связывание всего приводит к кошмару отладки, и я скучаю по ссылке на представление!

Мне просто интересно, как вы чувствуете MVVM против старого кода, стоящего позади. Что вам больше нравится и / или что вы обычно используете или рекомендуете?

Спасибо

Answer 1

Я определенно в меньшинстве на этом, но я склонен согласиться с @Shnitzel. MVVM и связывание, которое идет рука об руку с ним, являются отличными идеями, но они плохо обслуживаются текущими инструментами MS. Синтаксис для всех, кроме самых простых привязок, очень трудно понять правильно, и он значительно усложняется тем фактом, что WPF и Silverlight молча поглощают все ошибки. (Да, некоторые ошибки отображаются в окне отладки, но их недостаточно, и не достаточно подробно.) Вы можете использовать такие хаки, как написание преобразователя значения отладки, но факт остается фактом, что набор инструментов все еще довольно незрелый. (И еще есть моя стандартная жалоба, что привязка данных не является строго типизированной, а это означает, что инструменты не могут поймать ошибки за вас.)

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

Рассмотрим этот сценарий: у вас есть большое приложение с более чем 50 формами / страницами, и вы только что провели серьезный рефакторинг вашей модели и модели представления. В процессе вы переименовали группу классов и свойств и т. Д. Теперь найдите каждое место в вашем XAML, которое вам нужно изменить, чтобы отразить новые имена классов и свойств. Так много для тестируемости, а? Мало того, что IDE не поймает ваши ошибки привязки, компилятор не поймает их, и, что лучше всего, приложение даже не выдаст ошибку во время выполнения. Вы должны получить тестер для запуска всего приложения и убедиться, что все ваши привязки все еще выполняют то, что вы от них хотите. Ugggh. Уродливый и болезненный. По крайней мере, когда я делал вещи старомодным способом, компилятор сообщал мне, когда я что-то написал неправильно.

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

[Edit 12/10/2010 - MS недавно объявила, что SL5 будет иметь возможность отладки привязок данных , включая возможность устанавливать на них точки останова, чтобы вы могли видеть, что происходит. Это большой шаг в правильном направлении. Это все еще не решает, как я считаю, фундаментальную проблему: привязка данных не имеет проверки типов во время компиляции, но она несколько повышает полезность набора инструментов.]

Answer 2

Все это, ИМХО, куча ажиотажа в сфере супер-технологий, и в долгосрочной перспективе не будет служить НИКАКОЙ цели, кроме как направить разработку туда, где затраты на разработку могут нести бремя потери производительности ... т.е.офшорный.Это ужасно МЕДЛЕННО создавать функциональный интерфейс, который НИЧЕГО делает.Как будто все приложения представляют собой простые страницы контента, корзины покупок или сетки данных.Очень плохо.Итак, если приложение с несколькими ошибками, которые устраняются за несколько циклов выпуска, настолько плохое, мы просто обменяем это на систему, которую никто не сможет понять сквозной общей картины... для чего?Тестируемость?Какая куча полного дерьма.Как будто дни ошибок и исправлений уже прошли?Да, верно ... мой тест говорит 2 + 2 = 4, поэтому мое приложение не содержит ошибок.Правильно.

Итеративная разработка вернется, запомните мои слова.Как только истинные затраты на TDD станут более очевидными по сравнению с производством НЕКОТОРЫХ функциональных возможностей, необходимо как можно скорее.

Answer 3

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

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

Еще одно ОГРОМНОЕ преимущество заключается в природе MVVM, разделении GUI и бизнес-логики.Если вы работаете с дизайнерами, они все в мире XAML, говорят о градиентах, границах, затенении, а что нет.В то время как вы, программист с радостью кодирует вашу ViewModel с помощью юнит-тестов.Поэтому, когда у дизайнера есть готовый прототип, нужно просто подключить команды и привязки.Простой графический интерфейс готов =)

Answer 4

Теперь некоторые здесь используют MVVM, и с этим все в порядке. Некоторые нет, потому что они поднимают большинство задач разработчиков и не участвуют в каких-то крупных проектах с указанными дизайнерами, тестировщиками и многим другим. Тем не менее, я был в обоих и видел оба пути. Есть люди, которые прыгают по любому шаблону и должны его реализовать, несмотря ни на что. Даже небольшие приложения для управления небольшими данными разрабатываются в MVVM и других областях. Они будут запланированы и запланированы на недели, хотя некоторые из этих программ могут быть взломаны через несколько дней, но шаблоны и тестирование и многое другое должны быть выполнены. И, честно говоря, многие разработчики учатся на практике, и некоторые из этих шаблонов являются чрезвычайно сложными, потому что они сочетают в себе очень много шаблонов и методов абстрактного программирования.

Answer 5

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

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

Что касается командования, то это было для меня тяжело долгое время. Затем я обнаружил RelayCommand в MVVM Light. При этом довольно просто настроить метод для запуска с помощью команды. Лично я почти никогда не использую опцию параметра в моих командах. Я предпочитаю использовать только состояние внутри модели представления.

Answer 6

Полезность MVVM-подобного подхода зависит от объема и сложности приложения. С одной стороны, «не очень сложный, не очень полезный», а с другой - «много человеко-лет, которые невозможно построить без чего-то вроде MVVM».

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

Answer 7

MVVM имеет свои болевые точки - как и весь шаблонный код, необходимый для командования, беспорядка с синтаксисом привязки и невероятно глупыми взломами, которые необходимо закрыть форму.* Это все из-за отсутствия хорошего каркаса - это видео стало для меня большим откровением, если вы выберете правильный каркас, он может позаботиться обо всех неприятных деталях автоматически (и если вы можете 'найти хорошую платформу, написать свою собственную мини-платформу, которая решает ваши болевые точки легче, чем иметь дело с «голым» MVVM)приложения с меньшим количеством кода, чем у альтернативы.

Answer 8

С Статья Джоша Смита о MVVM :

В дополнение к WPF (и Silverlight 2) функции, которые делают MVVM естественный способ структурировать приложение, шаблон также популярны, потому что классы ViewModel легко для модульного тестирования. Когда логика взаимодействия приложения живет в наборе классов ViewModel вы можете легко написать код, который проверяет это. В смысл, виды и юнит-тесты просто два разных типа ViewModel потребители. Наличие набора тестов для ViewModels приложения обеспечивает бесплатное и быстрое регрессионное тестирование, что помогает снизить стоимость поддержание приложения во времени.

Для меня это самая важная причина использовать MVVM.

Раньше у меня были элементы управления, которые объединяли бы вид и модель вида. Но представление по существу имеет события мыши и клавиатуры в качестве входных данных и нарисованные пиксели в качестве выходных данных. Как вы проводите модульное тестирование или интеграционное тестирование? MVVM устраняет эту проблему, поскольку отделяет непроверяемое представление от тестируемой модели представления и сохраняет слой представления как можно более тонким.