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

Question

После 3-х месяцев программирования моего приложения на WPF я снова задумался о том, как я программирую свое приложение (я знаю, что, может быть, уже слишком поздно). В моем приложении я использую API программного обеспечения, которым управляет мой инструмент. У меня есть DAL, который содержит 16 классов, 3 из них - одиночные. У меня есть немного логики в .cs файлы и XAMLс курса. У меня вопрос, я вижу много комментариев о том, что приложение, написанное на WPF, должно использовать MVVM, и это сделает код более удобным и читабельным. Могу ли я преобразовать свой код в MVVM? каково это на самом деле значение MVVM (не Википедия или определение вручную)?

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

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

Answer 1

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

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

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

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

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

Есть и другие аспекты MVVM, но основная реализация такова.

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

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

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 вообще не содержит ссылки на View. Таким образом, представление может быть чем угодно, пока {Bindings} хранятся на месте.

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

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

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

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

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

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