Подтвердить что ты не робот

Является ли MVVM бессмысленным?

Является ли ортодоксальная реализация MVVM бессмысленной? Я создаю новое приложение, и я рассматривал Windows Forms и WPF. Я выбрал WPF, потому что это будущее и предлагает большую гибкость. Существует меньше кода и проще внести существенные изменения в пользовательский интерфейс, используя XAML.

Поскольку выбор для WPF очевиден, я подумал, что я могу пройти весь путь, используя MVVM в качестве моей архитектуры приложения, поскольку он предлагает совместимость, разделение и тестируемость блоков. Теоретически, это кажется красивым, как святой Грааль программирования пользовательского интерфейса. Это краткое приключение; однако, превратилась в настоящую головную боль. Как и ожидалось на практике, я обнаружил, что Ive торговал одной проблемой для другой. Я склонен быть навязчивым программистом в том, что я хочу делать все правильно, чтобы я мог получить правильные результаты и, возможно, стать лучшим программистом. Шаблон MVVM просто провалил мой тест на производительность и только что превратился в большой взломанный хак!

Очевидным примером является добавление поддержки диалогового окна Modal. Правильный способ - установить диалоговое окно и привязать его к модели представления. Это трудно. Чтобы воспользоваться шаблоном MVVM, вам необходимо распространять код в нескольких местах по всем слоям приложения. Вы также должны использовать эзотерические конструкторы программирования, такие как шаблоны и выражения lamba. Материал, который заставляет вас смотреть на экран, царапая голову. Это делает техническое обслуживание и отладку кошмара, ожидающего того, что я обнаружил недавно. У меня была хорошая работа, пока я не получил исключение во второй раз, когда я его вызвал, заявив, что он не сможет снова отобразить диалоговое окно после его закрытия. Мне пришлось добавить обработчик событий для функции закрытия в диалоговое окно, еще один в реализации IDialogView и, наконец, еще один в IDialogViewModel. Я думал, что MVVM спасет нас от такого экстравагантного хакера!

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

Извините, если мой ответ стал немного длинным, но не обвиняйте меня! Ваш вопрос также длинный.

Таким образом, MVVM не является бессмысленным.

Ясным примером является добавление поддержка диалогового окна Modal. правильный способ - установить диалоговое окно и привяжите его к модели представления. Получение это трудно работать.

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

Вот мое решение для этого конкретного примера:
Как пользовательский интерфейс обрабатывает определенный вход, не является ни одной из бизнес-моделей ViewModel. Я бы добавил код в файл View.xaml.cs, который создает диалоговое окно и устанавливает тот же экземпляр ViewModel (или что-то еще, если необходимо) в качестве своего DataContext.

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

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

  • Добавьте XAML в представление, и ничего в .xaml.cs
  • Пишите каждую логику приложения (за исключением вещей, которые будут напрямую работать с элементами пользовательского интерфейса) внутри ViewModel
  • Весь код, который должен выполнять пользовательский интерфейс, но не имеющий ничего общего с бизнес-логикой, входит в файлы .xaml.cs.

Я думаю, что целью MVVM является прежде всего разделение логики приложения и конкретного пользовательского интерфейса, что позволяет легко модифицировать (или полную замену) пользовательского интерфейса.
Я использую следующий принцип: View может знать и предполагать все, что он хочет от ViewModel, но ViewModel не может знать НИЧЕГО о представлении.
WPF обеспечивает хорошую модель привязки, которую вы можете использовать для достижения именно этого.

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

Материал, который заставляет вас смотреть на экран, царапая голову.

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

У меня был окошко, прекрасно работающее...

Зачем вам помещать ViewModel за поле about? Нет смысла в этом.

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

Да, поскольку сам факт того, что элемент пользовательского интерфейса находится в одном окне или в другом окне или является орбитальным Марсом в данный момент, не является проблемой для ViewModels. Разделение проблем

EDIT:

Здесь очень хорошее видео, название которого Создайте собственную среду MVVM. Это стоит посмотреть.

Ответ 2

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

Для обычного модального диалогового окна? Вы, конечно, делаете что-то не так - реализация MVVM не обязательно должна быть такой сложной.

Учитывая, что вы новичок как в MVVM, так и в WPF, вполне вероятно, что вы используете субоптимальные решения повсюду и неоправданно усложняете вещи - по крайней мере, я сделал это, когда впервые появился WPF. Убедитесь, что проблема действительно MVVM, а не ваша реализация, прежде чем отказаться.

MVVM, MVC, Document-View и т.д. - это старое семейство шаблонов. Есть недостатки, но нет фатальных недостатков, которые вы описываете.

Ответ 3

Я рассматриваю проблему с диалогими путем обмана. My MainWindow реализует интерфейс IWindowServices, который предоставляет все диалоги приложений. Мои другие ViewModels могут затем импортировать интерфейс служб (я использую MEF, но вы можете просто просто передать интерфейс через конструкторы вручную) и использовать его для выполнения необходимого. Например, вот что выглядит интерфейс для небольшого приложения моей утилиты:

//Wrapper interface for dialog functionality to allow for mocking during tests
public interface IWindowServices
{
    bool ExecuteNewProject(NewProjectViewModel model);

    bool ExecuteImportSymbols(ImportSymbolsViewModel model);

    bool ExecuteOpenDialog(OpenFileDialog dialog);

    bool ExecuteSaveDialog(SaveFileDialog dialog);

    bool ExecuteWarningConfirmation(string text, string caption);

    void ExitApplication();
}

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

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

Ответ 4

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

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

Ответ 5

Я нахожусь в середине довольно сложной разработки MVVM с использованием PRISM, поэтому мне уже пришлось справляться с такими проблемами.

Мои личные выводы:

MVVM vs MVC/PopUps и co

  • MVVM - действительно отличный шаблон, и в большинстве случаев он полностью заменяет MVC благодаря мощной привязке данных в WPF
  • Вызов уровня обслуживания непосредственно из ведущего - это законная реализация в большинстве случаев
  • Даже довольно сложные сценарии List/Detail могут быть реализованы чистым MVVM благодаря синтаксису {Binding Path =/}
  • Тем не менее, когда необходимо выполнить сложную координацию между несколькими представлениями, контроллер в обязательном
  • Можно использовать события; старый шаблон, который подразумевает сохранение экземпляров IView (или AbstractObserver) в контроллере, устарел
  • Контроллер может быть введен в каждый презентатор контейнером IOC
  • Призмы Служба IEventAggregator - это еще одно возможное решение, если единственным использованием контроллера является диспетчеризация событий (в этом случае он может полностью заменить контроллер).
  • Если представления должны быть динамически созданы, это очень подходящее задание для контроллера (в призме контроллер будет инъецирован (IOC) IRegionManager)
  • Модальные диалоговые окна в большинстве сводных приложений в большинстве случаев устарели, за исключением действительно блокирующих операций, таких как обязательные подтверждения; в этих случаях модальная активация может быть абстрагирована как услуга, называемая внутри контроллера, и реализуется специализированным классом, что также позволяет проводить расширенное тестирование уровня на уровне презентации. Контроллер, например, вызовет IConfirmationService.RequestConfirmation( "вы уверены" ), который вызовет отображение модального диалога во время выполнения и может быть легко высмеивается во время модульного тестирования.

Ответ 6

Как сам шаблон MVVM. Но библиотека управления WPF, поставляемая с поддержкой привязки данных NET 4.0, очень ограничена, она намного лучше, чем WinForm, но все же этого недостаточно для связывания MVVM, я бы сказал, что мощность составляет около 30% от того, что необходимо для связующего MVVM. < ш > Bindable MVVM: это UI, где ViewModel подключен с помощью View только с использованием привязки данных.
MVVM-шаблон относится к представлению объекта ViewState, он не описывает, как вы поддерживаете синхронизацию между View и ViewModel, в WPF привязывается к данным, но это может быть что угодно. И на самом деле вы можете использовать шаблон MVVM в любом наборе инструментов пользовательского интерфейса, который поддерживает события \callbacks, вы можете использовать его в чистом WinAPI в WinForms (я сделал, и он не намного больше работал с событиями \callbacks), и вы даже можете использовать его в Text Консоль, например, перезаписать DoS Norton Commander с использованием шаблона MVVM.

Короче: MVVM не бессмысленна, это здорово .NET 4.0. Библиотека управления WPF - это мусор.

Вот простое доказательство концепции ViewModel, с которой вы не можете привязывать данные в чистом MVVM режиме, используя WPF.

public class PersonsViewModel
{
    public IList<Person> PersonList;
    public IList<ColumnDescription> TableColumns;
    public IList<Person> SelectedPersons;
    public Person ActivePerson;
    public ColumnDescription SortedColumn;
}

Вы не можете привязать заголовки столбцов WPF DataGrid к данным, вы не можете привязать данные к выбранным строкам и т.д. и т.д., вы либо сделаете это простым образом, либо напишите 200 строк кода взлома XAML для этих 5 строк Простейший ViewModel. Вы можете только представить, как все становится хуже с помощью сложных ViewModels.
Таким образом, ответ просто, если вы не пишете приложение Hello World, используя bindable MVVM в WPF бессмысленно. Вы потратили большую часть своего времени, думая о взломе, чтобы привязать вас к ViewModel. Связывание данных приятное, но будьте готовы к откату до события 70% времени.

Ответ 7

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

  • Вид содержит конкретные элементы графического интерфейса пользователя и определяет внешний вид пользовательского интерфейса.
  • ViewModel представляет состояние и поведение презентации.
  • Модель может быть бизнес-объектом из уровня домена или службой, предоставляющей необходимые данные.

Но отсутствует:

  • Кто создает ViewModels?
  • Кто отвечает за рабочий процесс приложения?
  • Кто посредничает между ViewModels, когда им нужно общаться друг с другом?

Мой подход состоит в том, чтобы ввести (Use-case) Контроллер, который отвечает за недостающие точки. Как это работает, можно увидеть в примерах WPF Application Framework (WAF).

Ответ 8

Нет, это не бессмысленно, но трудно обернуть голову, хотя сам шаблон смехотворно прост. Там тонны дезинформации и различные группы, которые сражаются надлежащим образом. Я думаю, что с WPF и Silverlight вы должны использовать MVVM или вы будете над кодированием и пытаетесь решить проблемы в новой модели, а "старая" технология выигрывает форму, которая просто приводит вас к неприятностям. Это больше похоже на Silverlight, так как все требуется быть асинхронным (взломать это возможно, но вы должны просто выбрать другую платформу).

Id предлагает прочитать эту статью Упрощение WPF TreeView с помощью шаблона ViewModel  тщательно, чтобы увидеть, как MVVM может быть хорошо реализован и позволит вам изменить менталитет формы выигрыша на новый образ мышления в MVVM. Короче, когда вы хотите что-то сделать, сначала примените логику к ViewModel, а не View. Вы хотите выбрать элемент? Изменить значок? Не перебирайте элементы UI, просто обновляйте свойства моделей и привяжите привязку данных к nitty gritty.