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

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



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



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

608   4  

4 ответов:

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

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

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

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

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

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

Edit:

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

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

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

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

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

112  
2016-11-02 19:14:24

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

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

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

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

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

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

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

13  
2014-12-11 13:58:04

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

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

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

1  
2013-11-14 15:24:49

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

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

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

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

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

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

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

1  
2015-03-05 09:20:11

Comments

    Ничего не найдено.
Click here to cancel reply.