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

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

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

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, у меня есть только положительные эффекты из этого решения, например:

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

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

Ответ 1

мы можем наследовать наши не-XAML UserControls друг от друга

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

Я думаю, что если вы хотите сделать что-то вроде этого, я бы работал с безжалостными элементами управления, где вы определяете UI "PARTS", делая его очень Blendable. Вы получаете ссылку на элементы управления пользовательским интерфейсом через OnApplyTemplate. Эти элементы управления являются полностью стильными и наследуемыми. Это ваш вид, в котором вы будете использовать эти элементы управления и извлекать данные из привязки, передавая их своим бесполезным элементам управления. Просмотр, IMO, всегда должен быть клеем для виртуальной машины для привязки к этим типам элементов управления.

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

Высказывание "вы не понимаете MVVM" на самом деле не является аргументом против его подхода. Более понятный образец лучше, чем тот, который не является.

Ответ 7

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

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

EDIT:

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

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