Программисты WPF/Silverlight: излишество MVVM?
Я просто смешал чувства о MVVM. Кажется, что я должен кодировать так много для получения большинства коррективных вещей работать. Я пропускаю события (управление является такой болью), связывание всего приводит к кошмару отладки, и я избегаю иметь ссылку на представление!
Я просто задавался вопросом о Ваших чувствах MVVM по сравнению с простым кодом позади пути. Что Вы любите лучше и/или что Вы обычно используете или рекомендуете использовать?
Спасибо
5 ответов
Я определенно в меньшинстве по этому поводу, но я склонен согласиться с @Shnitzel. MVVM и связка, которая идет рука об руку с ним, - отличные идеи, но они плохо обслуживаются текущими инструментами MS. Синтаксис для всех привязок, кроме простейших, очень сложно получить правильно, и он значительно усложняется тем фактом, что WPF и Silverlight молча проглатывают все ошибки. (Да, некоторые ошибки отображаются в окне отладки, но их недостаточно и недостаточно деталей.) Вы можете использовать такие приемы, как написание преобразователя значений отладки, но факт остается фактом: набор инструментов все еще довольно незрелый. (И еще есть моя стандартная жалоба, что привязка данных не строго типизирована, а это означает, что инструменты НЕ МОГУТ отловить ошибки за вас.)
Я слышу всех, когда они настаивают на тестируемости, и я большой любитель автоматизированного тестирования. Но, по крайней мере, при текущем состоянии наших инструментов улучшенная тестируемость MVVM обходится довольно дорого.
Рассмотрим следующий сценарий: у вас есть большое приложение с более чем 50 формами / страницами, и вы только что провели серьезный рефакторинг своей модели и ViewModel. В процессе вы переименовали несколько классов, свойств и т. Д. Теперь найдите все места в вашем XAML, которые вам нужно изменить, чтобы отразить новые имена классов и свойств. Так много о проверяемости, а? Мало того, что среда IDE не поймает ваши ошибки привязки, но и компилятор не поймает их, и, что лучше всего, приложение даже не выдаст ошибку во время выполнения. Вы должны заставить тестировщика пройти через все приложение и убедиться, что все ваши привязки по-прежнему выполняют то, что вы от них хотите. Тьфу. Уродливо и болезненно. По крайней мере, когда я делал что-то по старинке, компилятор сообщал мне, когда я что-то ошибался.
Возвращение в свою пещеру, чтобы избежать пращей и стрел, быстро направило мой путь ...
[Редактировать 10.12.2010 - MS недавно объявила, что SL5 будет иметь возможность отлаживать привязки данных , включая возможность устанавливать на них точки останова, чтобы вы могли видеть, что происходит. Это большой шаг в правильном направлении. Он по-прежнему не решает то, что я считаю фундаментальной проблемой: привязка данных не имеет проверки типов во время компиляции, но это немного улучшает полезность набора инструментов.]
Из статьи Джоша Смита о MVVM :
В дополнение к WPF (и Silverlight 2) функции, которые делают MVVM естественный способ структурировать приложение, узор также популярны, потому что классы ViewModel легко провести модульное тестирование. Когда логика взаимодействия приложения живет в наборе классов ViewModel вы можете легко написать код, который его проверяет. В смысл, представления и модульные тесты - это просто два разных типа ViewModel потребители. Имея набор тестов для ViewModels приложения предоставляет бесплатное и быстрое регрессионное тестирование, что помогает снизить стоимость поддержание приложения в течение долгого времени.
Для меня это самая важная причина использовать MVVM.
Раньше у меня были элементы управления, которые совмещали представление и модель представления. Но представление, по сути, имеет события мыши и клавиатуры в качестве ввода и нарисованные пиксели в качестве вывода.Как вы проводите модульное или интеграционное тестирование чего-то в этом роде? MVVM решает эту проблему, поскольку он отделяет непроверяемое представление от тестируемой модели представления и сохраняет уровень представления как можно более тонким.
У MVVM есть свои болевые точки - как и весь шаблонный код, необходимый для команд, возня с синтаксисом привязки и невероятно глупые хаки, необходимые для закрытия формы.
- но -
Это все из-за отсутствия хорошей структуры - это видео было для меня большим открытием, если вы выберете правильный фреймворк, он позаботится обо всем неприятные части автоматически (и если вы не можете найти хороший фреймворк, написать свой собственный мини-фреймворк, который решает ваши болевые точки, проще, чем иметь дело с «голым» MVVM).
Просто посмотрите это видео и вы увидите, как с хорошей небольшой структурой вы можете писать приложения MVVM с меньшим количеством кода, чем альтернатива.
Люди упомянули тестирование, и это хороший момент. Еще один момент, на мой взгляд, - это возможность повторного использования, привязка одной и той же модели просмотра к разным представлениям. Например, возможно, у вас есть упрощенное представление для некоторых пользователей и более продвинутое для других.
Я вижу, как люди упоминают, что обработка событий - это боль и тому подобное. Существуют платформы MVVM, которые справляются с этим. На мой взгляд, также допустимо подключать обработчики событий к выделенному коду и вызывать методы модели представления из выделенного кода. Это, безусловно, лучше, чем не использовать MVVM из-за трудных времен, когда у людей могут быть события подключения.
Еще одно ОГРОМНОЕ преимущество заключается в природе MVVM, разделении графического интерфейса пользователя и бизнес-логики. Если вы работаете с дизайнерами, все они знакомы с миром XAML, говоря о градиентах, границах, затенении и многом другом. Пока вы, программист с радостью кодирует вашу ViewModel с помощью модульных тестов. Итак, когда у дизайнера готов прототип, остается лишь подключить команды и привязки. Готовый простой графический интерфейс пользователя =)
Полезность подхода, подобного MVVM, зависит от объема и сложности приложения. С одной стороны, это «не очень сложно, не очень полезно», а с другой - «много человеко-лет на создание, невозможно без чего-то вроде MVVM».
Тестируемость идет рука об руку с этим - приложения, достаточно маленькие и достаточно простые, чтобы MVVM чувствовали себя чрезмерно, также настолько малы и просты, что реальное покрытие модульными тестами просто фарс. Однако реальный мир обычно очень сложен, а это означает, что реальным приложениям нужны модульные тесты для поддержания качества, и им действительно нужен MVVM, чтобы их можно было тестировать и управлять. Любой, кто думает, что обойдется без них, сжигает огромное количество энергии, чего требуется совсем немного; или, что еще хуже, позволить серьезным проблемам качества маскироваться чем-то еще.