Каков ваш опыт отказа от MVVM для архитектуры WPF на основе UserControl?

Question

Мы создали большое приложение на основе библиотеки составных приложений и MVVM с использованием Infragistics элементов управления.

Чтобы сэкономить время и сделать приложение более простым, мы отменили требование MVVM . Теперь у нас нет Presenters или ViewModels, и наши представления стали простыми пользовательскими элементами управления, которые создаются следующим образом:

BaseEditor.cs:

using System.Windows.Controls;

namespace App
{
    public class BaseEditor : UserControl
    {
        public string Title { get; set; }
        public BaseEditor()
        {
            Title = "This was defined in the Base Editor.";
            Loaded += new System.Windows.RoutedEventHandler(BaseEditor_Loaded);
        }

        void BaseEditor_Loaded(object sender, System.Windows.RoutedEventArgs e)
        {
            StackPanel sp = new StackPanel();
            TextBlock tb = new TextBlock();
            tb.Text = Title;
            sp.Children.Add(tb);
            this.Content = sp;
        }
    }
}

CustomerEditor.cs:

namespace App
{
    public class CustomerEditor : BaseEditor
    {
        public CustomerEditor()
        {
            Title = "This was overwritten by the CustomerEditor.";
        }
    }
}

Window1.cs.xaml:

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

Помимо проблемы с тестируемостью и того факта, что при использовании WPF это "кажется грязным", я получил только положительные эффекты от этого решения, например ::1010 *

• мы можем наследовать наши пользовательские элементы управления не-XAML друг от друга
• мы используем столько кода, сколько хотим, что ускоряет разработку
• Прикрепление инфракрасных элементов управления непосредственно к нашему модельному классу, исходящему из веб-службы, устранило десятки небольших проблем связывания, которые у нас были с привязкой инфраструктуры к ObservableCollections
• даже в прямом WPF, отсутствие ObservableCollections создает такие проблемы, как невозможность создать простое меню уйти
• мы заменяем EventAggregator поочередно на прямые события, используя UserControls и код позади, что устраняет все виды проблем с событиями

Кто-нибудь еще, кто делал MVVM в WPF, имел подобный опыт? Вы сталкивались с реальными проблемами в долгосрочной перспективе?

Answer 1

мы можем наследовать наши пользовательские элементы управления не-XAML друг от друга

Я не понимаю. Как насчет MVVM исключает наследование?

мы используем столько кода, сколько хотим, что ускоряет разработку

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

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

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

Средства управления инфраструктурой крайне плохие. Там я это сказал. Если это вариант, не используйте их. Если это не вариант (и я тоже занимал эту должность), вы можете обойти многие проблемы с помощью поведения и других методов. Да, это хлопотно, но не вините MVVM - вините Infragistics за создание набора элементов управления, который так расходится с платформой WPF.

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

Я вообще не понимаю этого вопроса. ObservableCollections являются частью WPF, а не MVVM. И после прочтения вашего вопроса (опять же, я ответил на него вскоре после того, как вы его отправили), я бы сказал, что это просто ваше недопонимание того, как работает WPF - вообще никакого отношения к MVVM.

мы заменяем EventAggregator поочередно на прямые события, используя UserControls и код позади, что устраняет все виды проблем с событиями

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

Таким образом, это не столько дело против MVVM, сколько недостаток понимания. Я думаю, что вы плывете вверх по течению, и я бы посоветовал вам поближе взглянуть на MVVM. Это не «серебряная пуля» или шаблон «один размер подходит всем», но он может помочь создать фантастическую основу для ваших приложений WPF / SL при правильном использовании.

Answer 2

Я начал делать приложения WPF в шаблоне проектирования FFA (free-for-all), как этот, и я не буду возвращаться к нему, даже для небольших проектов. Хотя кажется, что вы более продуктивны, переходя прямо к исходному, голому металлическому интерфейсу, я пришел к выводу, что это больше восприятие производительности, потому что вы получаете мгновенное вознаграждение .

Рассмотрим: TextBlock.Text = "HelloWorld". Нет ViewModel для создания, не склеивая V и VM или настройки привязки. Нажмите F5, и мы увидим «HelloWorld» во всей его красе. Моя проблема с этим многогранна. Вот пара моих самых больших проблем:

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

  Гибкость пользовательского интерфейса . При использовании шаблона FFA, я нашел свой способность создавать пользовательский интерфейс в моем приложения были практически невозможны. Слишком много раз у меня был контроль, я не может проектировать в Blend. Было бы просто дать красную рамку с исключение. У меня был какой-то код использовал что-то еще, что не было можно использовать в режиме проектирования, вызывая вопрос. Переезд в MVVM магическим исправлены все мои проблемы с Blend. Если я получу красная граница в Blend сейчас, я ЗНАЮ это проблема с моей презентацией код. Ничего другого.

Таким образом, использование FFA может привести к быстрому выходу вашего V1, но PHB будет удивляться, почему v1.5 займет в четыре раза больше времени, чем v1. Мы все были там:)

Я думаю, что если вы захотите сделать что-то подобное, я бы поработал с элементами управления без внешнего вида, где вы определяете интерфейс «ЧАСТИ», делая его очень смешанным. Вы получаете ссылку на элементы управления пользовательского интерфейса через OnApplyTemplate. Эти элементы управления являются полностью стилевыми и наследуемыми. Это ваш вид, где вы будете использовать эти элементы управления и извлекать данные из привязки, передавая их своим элементам управления без внешнего вида. View, IMO, всегда должен быть связующим звеном, чтобы виртуальная машина могла связываться с такого рода элементами управления.

Для элементов управления Infragistics, с которыми у вас возникают проблемы, при условии, что вы используете Prism, вы должны сделать для него специальный адаптер региона. Это позволяет точно указать, каким образом элементы управления будут добавлены в инфраструктуру. Связывание не требуется. View инъекция будет работать так, как вы привыкли, после того, как вы ее встроите.

Я видел, что у некоторых людей есть подобные проблемы в MVVM, но я считаю, что он просто воспринимает MVVM слишком буквально. Не все выравнивается посланником. Мое ~ 40 (и растущее) приложение имеет около 5 составных событий. Я наследую элементы управления, использую инъекцию вида для вещей, которые даже не являются панелями или элементами управления содержимым. Иногда у меня есть codebehind для обработки кода / событий, связанных с презентацией ... И ... действительно, я защищаю MVVM и не даю @ $ &% о тестировании:)

Answer 3

Я попробовал это и в итоге вернулся к MVVM. В результате вы получите тот же беспорядок, управляемый событиями, в кодировке spagetti, который всегда возникал в Windows Forms. Если мне никогда не придется делать еще myLabel.Text = this.MyLabelText, я буду счастлив.

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

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

Answer 4

Я не согласен с этим, Я работал над крупномасштабным бизнес-приложением, используя элементы управления WPF, MVVM, WCF и Telerik. В начале использование MVVM было немного сложным, но как только мы решили с нашим дизайном и каркасом модели View это стало очень просто. Возможность повторного использования была очень легко достижима, и время разработки также было сокращено.

Кроме того, было действительно очень легко изменить элементы управления; в некоторых местах мы использовали базовые элементы управления WPF, которые позже заменили на элементы управления telerik и наоборот (поскольку в некоторых местах нам не требовались тяжелые элементы управления telerik, такие как GridView). Могу сказать, что в случае необходимости мы могли бы легко в любой момент легко заменить все элементы управления telerik другими элементами управления сторонних производителей или собственными элементами управления WPF.

Но да, нам пришлось реализовать некоторые обходные пути при использовании элементов управления telerik и написать некоторый код в codebehind для решения некоторых проблем (ошибок в telerik); весь этот код был чисто логикой представления.

Answer 5

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

Я бы с уважением не согласился (не понизив) с Андерсоном Аймсом по одному вопросу: мне не трудно придерживаться MVVM; Я нахожу это очень легко. Для меня это самый простой и естественный подход к разработке приложений WPF. Я использую его в рамках Composite WPF (Prism), который обеспечивает очень надежную среду для разделения сложных приложений.

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

Answer 6

Защитники MVVM излагают свое дело. Они утверждают, что альтернативой MVVM является обязательно код спагетти. То, что описывает Эдвард, все еще следует шаблону, но это не MVVM. Тот факт, что виды привязываются к моделям, похож на MVC. Код позади можно считать контроллером.

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

Сказать «вы не понимаете MVVM» на самом деле не аргумент против его подхода. Шаблон, который легче понять, лучше, чем шаблон, который нет.

Answer 7

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

По моему опыту, сочетание модели представления и привязки к событиям, кажется, выполняет свою работу до тех пор, пока не будет выработан более чистый подход, если потребуется.

EDIT:

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

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