Методология программирования WPF

Фактическое значение MVVM: UI – это не данные. Данные – это данные, пользовательский интерфейс – это пользовательский интерфейс .

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

Например, в других средах (таких как winforms), если у вас есть экран, содержащий текстовое поле, и кнопку, вы обычно добавляете обработчик события клика к кнопке, а затем читаете текст из текстового поля. в MVVM свойство Text для TextBox должно быть привязано к свойству string в ViewModel, и кнопка также должна быть привязана к команде в ViewModel.

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

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

Существуют и другие аспекты MVVM, но основная идея заключается в том, что.

Редактировать:

Я приведу конкретный пример этого для полноты ответа:

1 – Без MVVM WPF:

XAML:

Код позади:

 private void Button_Click(object sender, EventArgs e) { //Assuming this is the code behind the window that contains the above XAML. var lastname = this.txtLastName.Text; //Here you do some actions with the data obtained from the textbox } 

2 – MVVM WPF:

XAML:

ViewModel:

 public class MyViewModel { public string LastName { get; set; } public Command MyCommand { get; set; } public MyViewModel() { // The command receives an action on the constructor, // which is the action to execute when the command is invoked. MyCommand = new Command(ExecuteMyCommand); } private void ExecuteMyCommand() { //Only for illustration purposes, not really needed. var lastname = this.LastName; //Here you do some actions with the data obtained from the textbox } } 

Как видно из приведенного выше примера, ViewModel не содержит ссылок на представление. Таким образом, представление может быть любым, если {Bindings} сохранены на месте.

Клей, который волшебным образом заставляет их работать вместе, – это DataContext элементов интерфейса WPF, которое является объектом, с которым будут устранены все привязки.

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

Также имейте в виду, что MVVM является шаблоном проектирования, тогда как WPF является основой. В настоящее время MVVM применяется и в других технологиях (в настоящее время в Интернете много шума, связанных с MVVM, с JavaScript и тому подобное)

Я предлагаю вам прочитать книги, упомянутые в других ответах, а также этот учебник для более конкретных аспектов WPF.

Мой вопрос: я вижу много комментариев, что приложение, написанное в WPF, должно использовать MVVM, и это сделает код более удобным и удобочитаемым, можно ли преобразовать мой код в MVVM?

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

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

Конечно, вы можете переписать свое текущее приложение на шаблон MVVM. Просто удалите свой код и поместите его в свои модели просмотра, вспомогательные classы, classы репозитория, classы biz-logic и т. Д. Не попадайте в ловушку размещения в вас всех моделей взглядов, создавая прославленный MVVM код -за.

Я также использую SQL-запросы, и я прочитал статью об EF (Entity Framework), может ли MVVM и EF оставить вместе в одном проекте?

Конечно, они могут. Просто помните, что EF – технология доступа к данным, а MVVM – шаблон проектирования. Вероятно, вы используете EF в своих classах DAL, о которых вы упоминаете.

Если вы решите спуститься по маршруту MVVM, вы должны подумать об использовании frameworks, которая облегчает ее, например, Prism . О, и будьте готовы к довольному изучению и разочарованию.

Я определенно займусь DependencyInjection , используя фреймворк Unity .

Ваши classы Singleton могут быть зарегистрированы в контейнере DependencyInjection и введены в конструкторы других classов (например, ViewModels). Таким образом, могут быть другие classы DAL, которые необходимо регулярно создавать и вводить в classы.

DependencyInjection – это самый важный шаблон проектирования при разработке приложений для крупных корпоративных приложений и применим как для кода Client & Server. MVVM – хороший шаблон, но не будет решать проблему общей сложности приложений, связанной с связью зависимостей.

Это мои специфические для MVVM

1) Увеличивает «Смешиваемость» ваших взглядов (возможность использования Expression Blend для создания представлений). Это позволяет отделить обязанности от команд, которым посчастливилось иметь дизайнера и программиста … каждый из них может работать независимо друг от друга.

2) Логика просмотра «Беззвучный» . Представления являются агностическими из кода, который выполняется за ними, что позволяет использовать одну и ту же логику представления в нескольких представлениях или легко просматривать или заменять представление. Различают проблемы между «поведением» и «стилем».

3) Нет дублированного кода для обновления представлений. При кодировании кода вы увидите много запросов на «myLabel.Text = newValue», посыпанных повсюду. С MVVM вы можете быть уверены, что представление обновляется соответствующим образом, просто устанавливая базовое свойство и все его побочные эффекты.

4) Испытание. Поскольку ваша логика полностью агностична для вашего представления (нет ссылок «myLabel.Text»), модульное тестирование упрощается. Вы можете проверить поведение ViewModel без привлечения его представления. Это также позволило тестировать поведение поведения, основанное на тестах, что практически невозможно с использованием кода.

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

На самом деле MVP (с пассивным представлением, а не надзорным controllerом) на самом деле является всего лишь вариантом MVVM, на мой взгляд.