Толстые модели, худые ViewModels и немые виды, лучший подход MVVM?

Question

Благодаря щедрой справке по этому вопросу я собрал следующую структуру MVVM, которая отображает изменения модели в реальном времени в XAML (текущая дата / время), очень приятно.

Крутое преимущество этой установки что когда вы смотрите на ваш взгляд в Режим разработки Visual Studio или Смешайте, вы видите время, которое тикает на , Это означает, что во время разработки вы иметь доступ к данным в реальном времени от вашего модель.

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

Так что в настоящее время это мой любимый аромат MVVM:

1. Вид немой:

   • один ObjectDataProvider для каждого нужного вам объекта из вашей модели
   • каждый ObjectDataProvider отображается на метод в ViewModel (не свойство)
   • нет x: имя свойства в элементах XAML

2. ViewModel является тощим:

   • единственная вещь в вашей ViewModel - это методы , к которым привязывается ваше представление

3. Модель толстая:

   • модель реализует INotifyPropertyChanged для каждого из своих свойств.
   • для каждого метода в вашей модели представления (например, GetCurrentCustomer) в вашей модели есть соответствующий одноэлементный метод (например, GetCurrentCustomer).
   • модель позаботится о любой поточной функциональности в реальном времени, как в этом примере

Вопросы:

1. Те из вас, кто внедрял MVVM в реальных сценариях, является ли эта базовая структура, на которую вы также определились, и если нет, как ваша меняется?
2. Как бы вы расширили это, чтобы включить перенаправленные команды и перенаправленные события?

Следующий код будет работать, если вы просто скопируете XAML и код в новый проект WPF.

XAML:

<Window x:Class="TestBinding99382.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="clr-namespace:TestBinding99382"
    Title="Window1" Height="300" Width="300">

    <Window.Resources>
        <ObjectDataProvider 
             x:Key="DataSourceCustomer" 
             ObjectType="{x:Type local:ShowCustomerViewModel}" 
                        MethodName="GetCurrentCustomer"/>
    </Window.Resources>

    <DockPanel DataContext="{StaticResource DataSourceCustomer}">
        <StackPanel DockPanel.Dock="Top" Orientation="Horizontal">
            <TextBlock Text="{Binding Path=FirstName}"/>
            <TextBlock Text=" "/>
            <TextBlock Text="{Binding Path=LastName}"/>
        </StackPanel>
        <StackPanel DockPanel.Dock="Top" Orientation="Horizontal">
            <TextBlock Text="{Binding Path=TimeOfMostRecentActivity}"/>
        </StackPanel>

    </DockPanel>
</Window>

Код сзади:

using System.Windows;
using System.ComponentModel;
using System;
using System.Threading;

namespace TestBinding99382
{
    public partial class Window1 : Window
    {
        public Window1()
        {
            InitializeComponent();
        }
    }

    //view model
    public class ShowCustomerViewModel
    {
        public Customer GetCurrentCustomer() {
            return Customer.GetCurrentCustomer();
        }
    }

    //model
    public class Customer : INotifyPropertyChanged
    {
        private string _firstName;
        private string _lastName;
        private DateTime _timeOfMostRecentActivity;
        private static Customer _currentCustomer;
        private Timer _timer;

        public string FirstName
        {
            get
            {
                return _firstName;
            }
            set
            {
                _firstName = value;
                this.RaisePropertyChanged("FirstName");
            }
        }

        public string LastName
        {
            get
            {
                return _lastName;
            }
            set
            {
                _lastName = value;
                this.RaisePropertyChanged("LastName");
            }
        }

        public DateTime TimeOfMostRecentActivity
        {
            get
            {
                return _timeOfMostRecentActivity;
            }
            set
            {
                _timeOfMostRecentActivity = value;
                this.RaisePropertyChanged("TimeOfMostRecentActivity");
            }
        }

        public Customer()
        {
            _timer = new Timer(UpdateDateTime, null, 0, 1000);
        }

        private void UpdateDateTime(object state)
        {
            TimeOfMostRecentActivity = DateTime.Now;
        }

        public static Customer GetCurrentCustomer()
        {
            if (_currentCustomer == null)
            {
                _currentCustomer = new Customer 
                     {  FirstName = "Jim"
                        , LastName = "Smith"
                        , TimeOfMostRecentActivity = DateTime.Now 
                     };
            }
            return _currentCustomer;
        }

        //INotifyPropertyChanged implementation
        public event PropertyChangedEventHandler PropertyChanged;
        private void RaisePropertyChanged(string property)
        {
            if (PropertyChanged != null)
            {
                PropertyChanged(this, new PropertyChangedEventArgs(property));
            }
        }
    }
}

Answer 1

Вот мое мнение, за что оно стоит:

Я не совсем согласен с подходом, который вы предлагаете (за исключением глупого представления). В реальной жизни вам часто приходится использовать существующую модель: это может быть устаревший код, который у вас нет времени (или воли) для изменения, или даже библиотека, для которой у вас нет кода. На мой взгляд, модель должна полностью не знать, как она будет отображаться, и ее легко использовать в приложении, не поддерживающем WPF. Поэтому он не должен реализовывать какой-либо конкретный интерфейс, такой как INotifyPropertyChanged из INotifyCollectionChanged, чтобы сделать его пригодным для использования в MVVM. Я думаю, что вся логика, связанная с пользовательским интерфейсом, должна находиться во ViewModel.

Что касается RoutedEvents и RoutedCommands, они не очень подходят для использования с шаблоном MVVM. Я обычно стараюсь использовать как можно меньше RoutedEvents, а не RoutedCommands вообще. Вместо этого мои ViewModels предоставляют RelayCommand свойства, которые я связываю с пользовательским интерфейсом в XAML (подробности о RelayCommand см. В этой статье Джоша Смита). Когда мне действительно нужно обрабатывать события для некоторого элемента управления, я использую прикрепленное поведение, чтобы сопоставить события командам ViewModel (взгляните на реализацию Марлона Греча )

Итак, в итоге:

• тупой вид
• Большой и умный ViewModel
• Любая модель, которую вы хотите или должны использовать

Конечно, это только мой подход, и он может быть не лучшим, но я чувствую себя вполне комфортно с ним;)

Answer 2

Я согласен с Томасом. Мой совет любому по архитектуре WPF:

• Простые объекты POCO без INotifyPropertyChange, отслеживания состояния, BL и т. Д.
• Простые и маленькие ViewModels, которые уведомляют Представления точно в срок
• Простой пользовательский интерфейс многократного использования с интеллектуальной системой навигации, которая позволяет избежать сложных иерархий данных и сложных базовых моделей представления
• MVVM с подходом View First для простоты зависимостей
• Асинхронные операции с Задачами или Rx
• Простая тема
• Нет сложного надежного пользовательского интерфейса, сделайте его простым, просто воспользуйтесь возможностями композиции и связывания пользовательского интерфейса WPF
• Не стесняйтесь использовать программный код для динамического создания контента (формы, списки и т. Д.) И сэкономить значительное время на декларативной конфигурации глаз (относится к большинству случаев) - и для меня это обязательно в 2015 году. Используйте методы расширения для Свободный API для этого.