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

Ответ 1

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

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

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

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

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

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

Edit:

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

1 - без MVVM WPF:

XAML:

<StackPanel>
   <TextBox x:Name="txtLastName"/>
   <Button Content="Click Me" Click="Button_Click"/>
</StackPanel>

Код позади:

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:

<StackPanel>
   <StackPanel.DataContext>
       <my:MyViewModel/>
   </StackPanel.DataContext>
   <TextBox Text="{Binding LastName}"/>
   <Button Content="Click Me" Command="{Binding MyCommand}"/>
</StackPanel>

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 UI, которое является объектом, с которым будут привязаны все привязки.

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

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

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

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

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

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