Вам нужно использовать команды для отслеживания шаблона MVVM?

Question

Я занимаюсь изучением и пониманием теории и использования шаблона MVVM, используемого при программировании WPF.

Начиная с WinForms, у меня все еще есть такая тенденция, чтобы просто дважды щелкнуть кнопку, чтобы привести меня к обработчику событий с нажатием.

Читайте онлайн о MVVM, видимо, это должно быть никогда не будет сделано, потому что, ну ... я не уверен. Предлагается использовать интерфейс ICommand для инкапсуляции действий, которые вызывают UI/View.

Мне еще нужно прочитать , почему это предпочтителен. Если вы используете обработчики событий, вы все равно не нарушаете отношения View/ViewModel, потому что ViewModel все еще ничего не знает о представлении ... правильно?

Будет ли использование команд предоставлять дополнительную гибкость, которую обработчики событий не предлагают? Во всяком случае, я чувствую, что использование команд сделает код более искаженным в том смысле, что вам нужно отступить, чтобы найти логику ICommand. С обработчиками событий все в коде за View. Я что-то упускаю?

Так, по существу, использование обработчиков событий вместо команд нарушает шаблон MVVM?

Answer 1

С обработчиками событий все в коде под видом.

Это именно то, чего вы ДОЛЖНЫ избежать.

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

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

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

Кроме того, ваше ощущение, что

вы должны вернуться назад, чтобы найти логика ICommand

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

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

Answer 2

Это действительно зависит от того, что вы хотите сделать при нажатии кнопки.

Если вы просто хотите взаимодействовать с U.I. (например, изменяя видимость или другое свойство элемента управления), тогда противник против этого MVVM будет противником.

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