Рекомендации по разработке приложения WPF без использования MVVM или аналогичного

Question

Мы создавали следующую версию внутреннего толстого клиента, используя WPF / Prism (библиотека составных приложений) . Поскольку мы почти закончили с клиентом, наша команда была передана новому руководству, и вскоре после этого:

1. Затем нам было предложено отказаться от структуры Prism, чтобы все было просто. Это включает в себя не использование какого-либо типа инверсии управления.

2. Нам было поручено создать приложение WPF без использования MVVM или чего-либо подобного; и многое другое в русле традиционного приложения WinForm. Идея состоит в том, что если разработчик видит элемент управления в представлении конструктора Visual Studio, то он / она должен иметь возможность щелкнуть элемент управления и увидеть, что именно он делает, без необходимости проходить через модель представления (или аналогичную).

3. Теперь нам было поручено создать приложение WPF с использованием одного основного окна, использовать Управление кадром для содержания и использовать ленту вне рамки для элементов меню. Причина, по которой нам было предоставлено право использовать Frame Control:

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

   б. Когда новый кадр должен быть показан во фрейме, текущий вид (страница) будет закрыт / удален, и новый вид (страница) займет свое место в кадре.

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

Учитывая ограничения 1 и 2 выше, мы хотели бы представить другой метод построения приложения, который:

1. Может быть представлен в качестве альтернативы использованию «Методологии фрейма» (пункт 3 выше), но все еще обеспечивает функциональность того же типа.

2. Не использует MVVM (см. № 1 и № 2 выше).

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

Answer 1

Лично я бы попытался доказать, что использовал модель презентации Мартина Фаулера. (Это шутка, кстати ...)

По сути, вам дают ограничение: «Используйте WPF, но не используйте какие-либо функции, которые делают WPF пригодным для использования». Это действительно звучит так, будто ваши требования таковы, что вам было бы гораздо лучше объяснить разумно преимущества таких шаблонов, как MVVM.

Звучит так, будто странные требования сводятся к следующему:

Идея состоит в том, что если разработчик видит элемент управления в представлении конструктора Visual Studio, то он (-ы) должен иметь возможность щелкнуть элемент управления и точно увидеть, что он делает

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

Однако в крупномасштабном приложении разделение интересов является ключевым. Даже правильно разработанное приложение Windows Forms требует четкого разделения задач, но при программировании на основе событий это становится намного сложнее, особенно со стороны дизайнера. Если вы попытаетесь разработать крупномасштабное чистое приложение с использованием подхода, основанного на событиях, у вас будут обработчики событий, но все эти обработчики событий в конечном итоге должны будут делегировать свою работу отдельному компоненту.

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

---

Кстати - «обоснование» использования страницы вместо UserControl не имеет никакого смысла. Вы можете сделать то же самое, что вы описываете с помощью UserControls ... Единственная причина использовать фрейм и страницу - это если вы хотите воспользоваться преимуществами навигации, и в этом случае вы не можете утилизировать старые страницы напрямую (или они регенерируются постоянно). Кроме того, навигационные инструменты, вероятно, не будут использоваться с лентой - две концептуальные модели совершенно разные.

Answer 2

Есть критика MVVM, которая может быть применима к вашему проекту; однако наличие необоснованных требований к методологии программирования всегда приводит к катастрофе.

Одна из причин того, что у нас есть фреймворки и мы тратим время на построение слоев и разделение, заключается в том, чтобы избежать путаницы в коде, которая всегда возникает, когда вы можете «просто нажать кнопку в Visual Studio, чтобы увидеть код, который выполняется». 1003 *

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

Однако я уже много лет использую систему, которая обеспечивает простую межобъектную сантехнику, называемую в настоящее время Emesary, вы можете прочитать мое C # .NET Emesary пошаговое руководство .

Но в основном это позволяет моим кнопкам быть реализованным таким образом:

    private void addButton_Click(object sender, RoutedEventArgs e)
    {
        GlobalTransmitter.NotifyAll(new Notification(NotificationType.CreateRecipe));
    }

Это может быть ответом на вашу проблему. Он слишком раздут, маленький и такой простой, но он просто хорошо работает.

Я достиг решения второго вопроса, используя Window, пользовательский элемент управления для панели ленты (пользовательский элемент управления содержит представление списка) и другой пользовательский элемент управления для части Frame. Этот второй очевидный пользовательский элемент управления построен с использованием других пользовательских элементов управления с использованием очень простого класса представления. Все виды и элементы управления связаны с помощью Emesary.

Answer 3

В качестве школьного проекта мне пришлось разработать клиент WPF, который позволял бы использовать его нескольким людям одновременно. И я использовал Страницы. Мой вердикт: сэкономьте огромное количество усилий и используйте вместо этого UserControls.

Иногда Page Navigator (который вы будете использовать для прокрутки) имеет тенденцию вызывать ошибки и вызывать у вас много проблем. Может быть, это было мое дерьмовое кодирование, но кто знает?

Хотя я должен сказать, что элемент управления, называемый "Страницы", несколько вводит в заблуждение ... Я пошел "Эврика!" когда я их нашел и поклялся на них потом.

Я полностью согласен с # 2 (заметки MS отмечают!). Было бы здорово, если бы вы могли дважды щелкнуть по элементу управления, и он бы сразу перешел к его команде (или событию, если его команда отсутствует). Однако до тех пор, убедитесь, что вы организовываете ваши Views и ViewModels в отдельных папках.

Наличие двухэкранного (или очень широкого) экрана позволит вам открыть два экземпляра VS в проекте: один сфокусирован вокруг View, а другой вокруг ViewModel (мой личный выбор - использовать Expression Blend on the View). ).

Хотя это не очень большое приложение, мне удалось за несколько дней преобразовать свой проект в правильный MVVM (т. Е. ViewModel для каждого элемента пользовательского интерфейса, RelayCommands и Mediator), поэтому, как только вы поймете это, не слишком сложно для реализации. Кроме того, существуют инструменты (такие как RelayCommand Джоша Смита и Mediator Марлона Греча - кстати, совершенно бесплатно), которые делают MVVM вдвое сложнее и в два раза мощнее.

Использование WPF без MVVM похоже на попытку съесть рис без вилки. Было бы лучше использовать WinForms, если вы не собираетесь использовать преимущества WPF. Мои 2 цента.

Answer 4

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

Итак, помещая все, что я написал до сих пор, в "не то, что вы просили", вот что я предлагаю: вы все еще можете использовать объектно-ориентированный чистый подход, то есть у вас может быть объект модели, у которого уже есть метод для отображения информации пользовательского интерфейса. так что каждый объект будет производным от окна, так что вы потеряете на SOC, но вы все равно будете OOP / OOD.

Но LOL, следующий этап приведет вас к отделению модели от вида, чтобы не повторять один и тот же код во многих окнах с выводом данных, которые передают одни и те же данные ... так что ваше руководство одобрит MVC / MVP как хорошее решение ... и расстояние от него до MVVM довольно короткое, если они хотят WPF.

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