Comments 30
А как насчёт перспектив? В статье про это ничего нет. При взгляде со стороны складывается впечатление, что даже winforms оказались более живучими — до сих пор (в .net 6) правки вносятся, какие-то мелочи, но улучшаются. Не выйдет так, что при схожей "не-кроссплатформенности" и "устаревшести" накидать формы для типичных приложений на пару экранов окажется быстрее и проще?
Добавлю свои соображения, как разработчик GUI на WPF.
Если кратко, то перспективы у WPF вполне себе неплохие. Microsoft сделала очень правильную вещь, открыла код .NET и WPF. Репозиторий WPF активный, пулл-реквесты мержутся, roadmap адекватный. Впрочем WinForms себя чувствуют даже лучше WPF. И в целом для простых GUI задач я советую выбирать WInForms.
Но а если длинно, то Microsoft достаточно сильно запуталась в своих GUI фреймворках. WinForms это удобная обертка над Win32 API, она никуда не денется. Но WinForms тесно завязан на визуальный дизайнер форм, поэтому масштабное GUI на нем писать сложно.
WPF очень красив архитектурно со своей MVVM моделью и рендерингом на DirectX. Первоначально он оказался не таким быстрым, как планировался и достаточно сложным. Но со временем детские проблемы были решена, и он завоевал ведущую роль в разработке GUI под Windows.
Но потом Microsoft подзабила на WPF и стала развивать концепцию UWP. UWP это приложения, отделенные от Win32API, живущие в своей песочнице, но способные работать на разных устройствах. Но UWP приложения так и не завовевали популярность. И получилась так сказать фрагментация платформы Windows. Одновоременно существовала старая добрая Win32, но совсем списывать в утиль UWP Microsoft не захотела.
Новая иницатива Microsoft это создание нового универсального WindowsAPI, объединяющая Win32 и UWP. И новый GUI фрейморк WinUI3. Недавно была выпущена версия 1.0. Но по обсуждениям в GitHub пока это все жутко тормозное и глючное. И не факт, что взлетит.
Плюс в Microsoft пошла новая инициатива, все пересписать на Web технологии. По крайней мере, лобби этого направление сильно.
К счастью, Microsoft наконец объединила .NET и .NET фреймворк в единую платформу .NET и открыла код. Все это дало новую жизнь WinForms и WPF.
Так что на текущий момет времени если писать сложное GUI под Windows desktop не по web технологиям, то WPF почти безальтернативый выбор. Собственно поэтому он сейчас достаточно неплохо чувствует, развивается и его будущее выглядит вполне неплохим.
Спасибо. Как раз живого мнения и хотелось услышать. Фрагментация GUI-фреймворков под Windows, примерная история (даже можно сказать чехарда с winui3 через uwp, через "modern") и то, что WPF не "флагман" мне известно.
Я выбрал WPF потому, что он актуален сейчас и скорее всего следующие фреймворки под desktop будут XAML-based и исповедовать подход MVVM, поэтому переписать будет легче. Но это мое видение, возможно пойдут и в какую-то другую сторону.
В моей области WPF очень популярен для разработки приложений для медицинской диагностики и медицинской визуализации. В таких приложениях обычно маловато типовых форм, и необходим достаточно сложный кастомный GUI с большой долей графики и анимации.
Типовой пример это приложение Varian Eclipse для планирования протонной терапии.
Десктопные приложения в паттерне mvvm. Вообще очень похоже на ангулар по ощущениям от разработки.
Microsoft пилит MAUI, я думаю в нем как минимум ReactiveUI, LiveCharts будут актуалны. Да и старые фреймворки не уходят мгновенно со сцены. Да и кстати, библиотеки перечисленные в статье также можно применять в WinForms.
Спасибо за статью! Добавлю несколько библиотек от себя
WPF UI -- современная библиотека визуальных стилей, молодая и активно развивающаяся
OxyPlot -- библиотека 2D графики, тянет real-time отображение
Helix Toolkit -- высокоуровненая библиотека 3D графики
Спасибо, OxyPlot как-то пропустил.
Это тоже неплоха ModernWpf
Еще Xceed WpfToolkit добавил бы
Я обычно беру HandyControl по тулкит и ui. Может кому тоже интересно будет потыкать.
"Джентельменский набор" для WPF у вас перечислен в содержании:
1 - Инфраструктура
Обработка исключений
Настройка IoC
Маппинг объектов
2 - Реализация MVVM - паттерна
Модель
Представление
Валидация
Команды
Отображение динамических данных
3 - Визуальные темы и элементы управления
Стиль приложения
ReactiveUI - это уже вкусовщина и личные предпочтения.
а писать для контролов вью-модели (ака GaugeControlViewModel) - это вообще дурной тон. ButtonViewModel, TextBoxViewModel в природе ведь не существуют, и хорошо. Контрол должен работать одинаково, независимо как получены значения свойств: через биндинг, цепочку биндингов, или константное значение в xaml:
<GaugeControl Total="36.6"/>
<GaugeControl Total="{Binding ElementName=TestNumericUpDown, Path=Value}"/>
Там еще какой-то подозрительный GaugeBuilder, который во вью-модель затянул визуальные характеристики элемента, которым там не место вообще. Джентельмены настраивают цвет фона (Background) по умолчанию в стилях по умолчанию.
И вообще, можно поподробнее, как вы собираетесь увязать этот GaugeControl с MVVM? Простая задача: есть N физических приборов (датчиков давления), которые считываются из конфига, в единственном окне приложения надо отображать текущие показания каждого из них на собственном GaugeControl. Загрузка списка датчиков и считывание показаний уже реализованы в классе PressureMonitor
class Sensor { public string Name {get;set;} public double Pressure {get;set;} }
class PressureMonitor { public ObservableCollection<Sensor> Sensors { get; } }
осталось только отобразить
ReactiveUI - это уже вкусовщина и личные предпочтения.
Вы правы, это моё предпочтение.
писать для контролов вью-модели (ака GaugeControlViewModel) - это вообще дурной тон
На мой взгляд, удобно было бы разделить представление от модели как и для окна, не раздувая класс view.
Там еще какой-то подозрительный GaugeBuilder, который во вью-модель затянул визуальные характеристики элемента, которым там не место вообще. Джентельмены настраивают цвет фона (Background) по умолчанию в стилях по умолчанию.
Спасибо, учту, в следующих версиях вынесу в стили.
И вообще, можно поподробнее, как вы собираетесь увязать этот GaugeControl с MVVM?
Буду решать задачу по мере наступления. Сейчас у меня число сенсоров в устройстве вполне определенное и навряд ли в будущем добавится.
Для кроссплатформенности и xaml wpf style возможно лучше сразу начинать на Авалонии писать. Если вдруг потом приложение может выйти где-то кроме windows
Avalonia я смотрел, она тоже использует Reactive Extensions. Но меня остановило другое - в Rider визуальный редактор представлений не работает, а с WPF проблем нет. А цели сделать мультиплатформенное приложения у меня не было.
Пробовал использовать LiveCharts (1.0), отвратительная скорость отрисовки - несколько секунд на 500 точек stepline графика. Но ничего лучше не попалось из бесплатного.
Попробуйте LiveCharts2. Также можно посмотреть на пример RealtimeDemo в библиотеке OxyPlot. На моей машине рендеринг графика из 20000 точек идет со скорость 60 FPS.
ScottPlot не пробовали?
Вот про графики очень интересно. А как себя ведут данные плагины, если входных точек больше чем 10000 (например, открыть данные по уровню/давлению за полгода/год)? Как влияет на память и отрисовку?
Мои рекомендации:
Для работы с xaml(любым, не только WPF) - https://github.com/Xavalon/XamlStyler - Форматирует ваш .xaml код согласно вашей конфигурации - https://github.com/Xavalon/XamlStyler/wiki/External-Configurations. Делает это по Ctrl+S при работе с .xaml, очень удобно.
Начните разделять понятия View и Control - View это какой-то специфичный для конкретного приложения UserControl или Window, который имеет ViewModel. А Control имеет только bindable Dependency Properties, и может быть перенесен из проекта в проект.
WPF и Material Design in XAML поддерживают отдельную валидацию для каждого контрола потому что ReactiveValidationObject реализует INotifyDataErrorInfo. Нет необходимости создавать отдельный контрол для вывода ошибок(если это не обусловлено дизайном, конечно). Есть минус - не поддерживаются code-behind биндинги. Для настройки отображения ошибки есть material:ValidationAssist.
Код MainWindow должен заканчиваться на InitializeComponent. Весь тот код из код бихайнда должен уйти.
Биндинги должны быть во вью, а вью модель подставляться снаружи, а не с помощью локатора.
GaugeControl - аналогично, дичь какая-то. Еще и вью модель занимается цветами и конвертацией лейблов для представления.
Проблема WPF/UWP технологий я думаю в том что нет развития XAML-а как декларативного языка. Система привязки и MVVM дак вообще не развивается. Из последних инноваций только x:Bind можно вспомнить и то это для очень узких кейсов. Нет сильной готовой библиотеки от Microsoft для этого. По сути они вообще не развивают это направление, в голом проекте тебе надо самому буквально с нуля делать реактивность. Из-за чего и получилось что какие-то конторы делают свои велосипеды, другие делают библиотеки количество которых слава богу не приближается к таковым в JavaScript но все равно очень большое и самое главное в них авторы по разному представляют как что должно работать. Т.е. например переходя с одной работы на другую вероятность там встретить похожую библиотеку или вообще какую-нибудь знакомую тебе опенсорсную крайне мала. А система привязок к сожалению очень сильно сдает, если хотя бы раз делать реактивность на JS с библиотеками вроде Vue.js/Angular/etc когда прямо в шаблоне можно просто написать property1 > property2 ? "value1" + property3 : "value2" то возвращаясь к конвертерам и простыне по типу "this.OneWayBind(ViewModel, vm => vm.Series, v => v.Plot.Series) .DisposeWith(disposable); " становится очень грустно. На маленьких и ближе к средним проектах это впринципе не особо заметно но когда проект большой все эти недостатки начинают сильно бить по скорости разработки и негативно сказывать на объеме кода. Мне кажется что развитием было бы либо замена XAML на что-то новое менее многословное либо как поступили в Asp.Net придумав Razor который позволяет писать Html с динамическими вставками, также круто было бы если бы можно было писать XAML с вклиниванием C# которым было бы легко генерить некоторые куски код.
Т.е. например переходя с одной работы на другую вероятность там встретить похожую библиотеку или вообще какую-нибудь знакомую тебе опенсорсную крайне мала.
Серьёзно? Как минимум у нас и в контексте WPF везде натыкаешься на одно и тоже.
также круто было бы если бы можно было писать XAML с вклиниванием C# которым было бы легко генерить некоторые куски код.
Вообще не круто на мой взгляд. Потому что потом задолбаешься в таком искать ошибки. Мне уже сейчас хватает умельцев, которые логику в code-behind "прячут"....
Серьёзно? Как минимум у нас и в контексте WPF везде натыкаешься на одно и тоже.
Я работал на нескольких проектах и на них использовались Prism, MVVM Light, Caliburn.Micro, MvvmCross, ReactiveUI, Cinch в остальных были свои велосипеды. Тут еще стоит упомянуть что хоть все они и решали одну и ту же проблему но делали это со своими ньюансами. Т.е. просто пересесть с одной на другую поменяв названия методов не представляется возможным. Незнаю может это мне так повезло...
Джентльменский набор для создания WPF-приложений