Что изучать: WinForms или WPF?

Вот скажите, как это понимать, когда я только начал читать книги, мне писали «Начинайте с консольных приложений». Потом когда я прошёл этот курс, в другой книге уже начали говорить о WinForms, и сейчас я начал читать другую книгу, там автор вообще пишет:

Зачем писать под WinForms, ведь её элементы почти не менялись за последние 10 лет, учите лучше WPF

Я сейчас вообще как ёжик в тумане. Что учить? На чём остановиться? Что ждёт дальше? Может быть, я поучу WPF, а в другой книге уже будут говорить о новом более красочном написании приложений? Можете помочь распутаться и всё расставить по полочкам. пожалуйста.

4 ответа 4

Если Вас интересует программирование desktop-приложений под Windows, то лучше остановиться на WPF, так как:

• это просто самая новая технология на данный момент
• использует 3D-ускоритель для отрисовки интерфейса
• ну и готовых возможностей по «украшению» интерфейса здесь гораздо больше

Хотя, если Вы будете использовать WinForms, приложения будут также отлично работать, так что выбор за Вами.

Насчёт того что ждёт дальше, то до выхода Windows 8 нкаких изменений не планируется. Но как обещают в Microsoft, после её выхода появится возможность разрабатывать интерфейс desktop-приложений используя HTML+CSS+JS.

Да, смотря что ты хочешь создавать. WPF больше подходит для крутых компов, где стоит минимум XP, с .NET 3.0. Библиотека тяжелая, но в Windows Vista уже стоит по умолчанию. Но за эти неудобства WPF дает хорошие преимущества почти во всем, но только на Windows. WindowsForms проектировать можно и даже предпочтительнее, у него есть следующие преимущества над WPF (сколько помню, столько и напишу)

1. SDI и MDI приложения (хотя есть библиотеки для эмуляции)
2. легче организовывать интерфейс OpenGL, DirectX
3. Теоретически кроссплатформенно за счет наличия MONO Framework
4. GDI+ легче в обращении (но медленнее), чем накрученная render-система в WPF
5. Вопреки распространённому заблуждению, поддерживают и полупрозрачные окна

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

Лично я (правда, вместе с Microsoft) порекомендую приступать к изучению UWP, Universal Windows Platform. Microsoft усиленно (но, к сожалению, не слишком то эффективно) проталкивает эту технологию, и, судя по всему, будет проталкивать ее еще определенное время, пока в очередной раз не сменится top management.

Опять-таки, программирование для WPF и UWP имеет много общего, так, что освоив UWP, вы без особого труда сможете писать и стандартные Windows приложения, а не только совместимые с Microsoft Store.

Кроме того, умение программировать UWP приложения привлекательно еще в чисто практическом смысле: освоив это, вы сможете опубликовать свое приложение в магазине, и сделать его доступным (потенциально) сотням миллионов пользователей. Не факт, конечно, что ваше приложение будет пользоваться хоть каким-то успехом, но уж несколько сотен закачек получите по любому. А работа с реальным проектом, и реальной отдачей — это лучшая практика для начинающего программиста, на порядки полезнее выполнения «стандартных» упражнений из учебника, уж поверьте мне на слово!

Почему все пишут приложения на WinForms если WPF лучше? [закрыт]

Хотите улучшить этот вопрос? Переформулируйте вопрос так, чтобы на него можно было дать ответ, основанный на фактах и цитатах.

Закрыт 3 года назад .

Очень часто на этом форуме встречаются вопросы которые начинаются таким образом

Я лично пробовал писать на Win Form и на WPF, и, как мне показалось, WPF более точный, более красивый в плане дизайна UI элементов. К тому же, в комплекте в WPF идёт замечательнейший язык Xaml, с которым работать намного легче чем с C# кодом внутри WinForms.

В связи с этим и задаюсь вопросом: какие преимущества есть у Win Form перед WPF и почему многие пишут на Win Form, хотя у них устарелый дизайн и они не поддерживаются?

4 ответа 4

У WPF и правда масса преимуществ перед WinForms. Особенно серьёзным преимуществом я бы назвал понятие привязки ( Binding ) и DataContext , которые радикально облегчают написание правильно структурированных программ, в которых представление отделено от модели, бизнес-логики и контента.

(Не то, чтобы на WinForms невозможно было писать правильно, это намного сложнее, и требует ручной работы.)

Но следствием этого и обратной стороной является гораздо более высокая сложность WPF как фреймворка, намного более высокий порог вхождения в WPF и в правильные методики программирования на нём. Ведь сила WPF проявляется именно когда вы начинаете отделять контент от представления, без этого он ненамного лучше WinForms.

Тем, у кого есть опыт программирования на MFC или похожих UI-фреймворках, намного легче перейти на практически аналогичный WinForms, чем учить новые (хотя бы и более удобные и продуктивные) концепции, которые помогают лёгкому, удобному программированию на WPF.

Думаю, именно это является основной причиной того, что WinForms всё ещё существует.

Не знаю как другие, но лично я не помню тот момент когда последний раз использовал WinForms, если десктоп — лишь только WPF и как бы высокопарно это не звучало, в этой среде он до сих пор впереди планеты всей. При этом не важно, это кровавый enterprise или приложение с «бабочками и цветочками».

• Декларативное программирование, web подобная модель компоновки.
• Независимость от разрешающей способности, аппаратное ускорение, поддержка мультисенсорного ввода.
• Стили, триггеры, шаблоны, анимация, аудио и видео, команды, мощная система привязки, маршрутизируемые события.
• Продвинутые возможности для рисования.
• Приложения со страничной организацией.

и куча всего. Кроме того идеи, принципы и философия, которые положены в основу данной технологии, мне очень импонируют, близки и симпатичны. При этом я не являюсь каким-то ярым противником WinForms или фанатиком WPF, но просто если на секунду вдуматься и поразмыслить чего бы стоило сделать на «формах» то что в WPF реализуется минут за 5 или 10, невольно понимаешь всю мощь и те возможности, которые эта технология предоставляет.

При этом как все мирское, WPF не идеальна и не лишена недостатков, но просто плюсов все-равно больше и это факт.

Скорее всего, это новички, которые только начинают учить .NET. Естественно, они начинают с более простой в изучении WinForms. И им не важно, что там что-то устарело, не поддерживается и т. д. Их цель — научиться писать программы.

По поводу устарелого дизайна, я вас не понял.

По поводу поддержки Win Forms мне кажется она никуда не делась, в этом можно убедиться почитав новости про Visual Studio 2017 и .net 4.7.

Лично мои наблюдения:

WPF говорит от потрясающем быстродействии в отрисовке элементов на экране благодаря работе на DirectX. У меня комп прекрасен всем — и CPU и GPU, но, по факту, отрисовка на экране у Win Forms гораздо быстрее (GDI тоже на месте не стоит).

Контрол DataGrid на WPF крайне сырой(по крайней мере пару лет назад был). Это самый важный контрол для представления данных вообще. Он должен быть очень универсальным, именно такой он в Win Forms, но не в WPF. Для виртуализации данных в DataGrid (WPF) можно использовать только виртуализацию самого источника данных через DataSource.

В Win Forms с DataGridView можно делать буквально все, что только угодно благодаря старому доброму механизму событий(CellVlueNeeded и CellValueFormating), причем очень просто (ну и DataSource тоже на месте).

Кстати, может кто то подскажет, появился способ в DataGrid поставить програмно фокус в строку номер N не прибегая к коду в 30 строк с применением рефлексии?

На мой скромный взгляд WPF хорош для приложений где летающие и пархающие кнопочки в виде звездочек важнее всего остального.

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

В пользу WPF скажу только, что сам принцип построения интерфейса в нем очень интересен тем, что похож на таковой в интернет-страницах. Это очень интересно, но пока сыро (до сих пор! Когда был впервые представлен WPF!?). И да, я не обожаю XAML.

WPF и Windows Forms 2021

WPF и Windows Forms

Windows Presentation Foundation (также известный как WPF) представляет собой графическую подсистему. Он используется для визуализации пользовательских интерфейсов в приложениях на базе Windows. С самого начала WPF (известный тогда как «Avalon») был выпущен как часть .NET Framework версии 3.0. Затем он использовался для удаления зависимостей от устаревшей подсистемы GDI. WPF построен на DirectX — это обеспечивает аппаратное ускорение. Он также позволяет использовать современные функции пользовательского интерфейса — прозрачность, градиенты и преобразования. Это согласованная модель программирования для создания приложений и обеспечивает определенное разделение между пользовательским интерфейсом и бизнес-логикой.

Windows Forms — графический интерфейс прикладного программирования (также известный как графический API). Это функция Windows .NET Framework и обеспечивает доступ к собственным элементам интерфейса Microsoft Windows. Он выполняет эту задачу, обертывая Windows API, который уже существует в управляемом коде, то есть, требует код, и будет выполняться только под управлением виртуальной машины Common Language Runtime, в результате чего получается Bytecode. Он часто считается заменой для библиотеки классов Microsoft Foundation на базе C ++; однако он не обеспечивает модель, которая сопоставима с контроллером представления модели (или MVC). Таким образом, некоторые библиотеки после рынка и сторонних разработчиков были созданы для компенсации.

WPF предлагает новую альтернативу языка разметки, которая известна как XAML. Это другое средство определения элементов пользовательского интерфейса и отношений с другими элементами пользовательского интерфейса. Приложение, которое определяется как WPF, может быть развернуто на рабочем столе или размещено в веб-браузере. Он также способен обрабатывать богатый контроль, разработку и разработку визуальных аспектов программ, выполняемых Windows. Его целью является, в частности, унификация ряда приложений, включая пользовательские интерфейсы, 2D и 3D-чертежи, фиксированные и адаптивные документы, расширенную типографику, векторную графику, растровую графику, анимацию, привязку данных, аудио и видео. WPF содержит множество функций, включая, но не ограничиваясь ими, графические службы, привязку данных, параметры макета и шаблона, а также опции эффектов.

Windows Forms — это приложение, управляемое событиями, которое поддерживается Microsoft .NET Framework. Что отличает Windows Forms от стандартных пакетных программ, так это то, что большую часть времени он проводит, ожидая, когда пользователь начнет действие — например, заполнив текстовое поле или нажав кнопку. Это действительно основано на взаимодействии пользователя с компьютером. Существует альтернативная версия Windows Forms, известная как Mono. Это проект под руководством Novell, разработанный для создания совместимого с Ecma совместимого с .NET набора инструментов.

1. WPF — это графическая подсистема, которая отображает пользовательские интерфейсы в приложениях на базе Windows; Windows Forms — это графический API, который обеспечивает доступ к элементам интерфейса Microsoft Windows.

2. WPF — это альтернатива языка разметки, которая определяет элементы пользовательского интерфейса и отношения с другими элементами пользовательского интерфейса; Windows Forms — это приложение, управляемое событиями, поддерживаемое платформой Microsoft .NET Framework.

Сравнение производительности UI в WPF, Qt, WinForms и FLTK

Под мерой производительности UI будем понимать количество откликов на действия пользователя в единицу времени. А под откликом — запрашиваемую пользователем реакцию приложения.

Малым временем отклика можно объяснить ряд предпочтений пользователя:

1. Предпочтение аналоговых интерфейсов цифровым (когада возникает задержка на обработке цифрового ввода);
2. На заре Windows, — предпочтения пользователей работать с DOS программами в «текстовом режиме», а с не GUI аналогами в Windows (время отклика в текстовом режиме тогда было заметно меньше на сходной платформе);
3. Предпочтение реальных игровых консолей их эмуляторам (эмуляторы часто имеют время отклика отличное от времени отклика оригинальных консолей);
4. Предпочтение пользователей iOS и Android относительно WinCE и Symbian (среди прочего, например в iOS ставилась цель быстрого отклика и поддержки 60 FPS, Android хотя и не ставил таких целей был заметно отзывчивее WinCE и Symbian);
5. В автомобилях — неоднозначное отношение пользователей к автоматическим коробками передач, электронной педали газа и некоторым другим системам вносящим задержку между управляющим воздействием и реакцией на него (это относится к наименее продвинутым версиям этих решений).

Большое время отклика является по сути «обратной связью с запаздыванием», про которую более подробно можно прочитать тут: «Обратная связь с запаздыванием в кране с горячей водой, марсоходе и демографической пирамиде».

Сравнение производительности

Задержка реакции на ввод пользователя в цифровых системах естественна и неизбежна. Однако в UI для восприятия значение имеют только те задержки, которые пользователь в состоянии ощутить. Например, в восприятии визуальной информации среднестатистический пользователь не способен различить задержки менее 1/60 секунды, поэтому дальнейшее уменьшение времени визуального отклика вряд-ли будет оправдано.

Рассмотрим отзывчивость пользовательского интерфейса библиотек WPF, Qt, WinForms и FLTK. Трудоемко измерить отзывчивость всех контролов этих библиотек, и сложно в каждом случае измерить интервал между вводом пользователя и реакцией контрола на этот ввод. Поэтому, немного упростим задачу оценки. Тестировать будем один, но сложный, и в целом показательный контрол, присутствующий во всех библиотеках — DataGrid. Отзывчивость будем мерить по FPS в отклике на скроллинг содержимого этого контрола. Для того чтобы избежать подсчета неполных кадров, будем использовать двойную буферизацию.

Во время скроллинга грида, мы так или иначе мы проверим основные механизмы библиотеки отвечающие за реакцию на ввод, рендеринг контролов, текста, обработку визуального дерева контролов, и отчасти композицию. Это даст нам возможность оценить потенциал библиотеки для работы с нагруженным UI.

Для каждой библиотеки я подготовил по тестовому приложению, заполняющих грид данными одинакового вида. Эти данные — 5000 строк по 20 колонок с некой произвольной информацией (считаю такое количество строк и столбцов близким к реальным максимальным потребностям отображения сложных объектов). Я не оптимизировал заполнение грида, поэтому не стоит придавать значения тому, что для некоторых библиотек он заполняется медленно. Производительность будем мерить уже после того как грид заполнен.

Производительность я проверял только под Windows (хотя библиотеки, за исключением WPF кросплатформенны), для проверки был написан счетчик FPS (только для Windows и 32 битной глубины цвета) определяющий изменения кадра по верхней части основного экрана. Погрешность счетчика может быть около 1 кадра.

Методика измерения производительности:
1. Запускаем счетчик FPSCounter.exe.
2. Запускаем одно из тестовых приложений FltkGrid.exe, FormsGrid.exe, QtGrid.exe или WpfDatagridTest.exe и разворачиваем его на весь основной экран (это необходимо т.к. детектируется только изменение верхней части кадра на основном экране)
3. Двигаем бегунок вертикального скроллера грида вверх и вниз до упора, во время движения бегунка смотрим значение FPS в верхнем левом углу экрана или в окне счетчика. (для получения максимальных значений FPS двигать бегунок надо быстро, иначе мы упремся в собственную «производительность», а не в производительность UI)

Измерения FPS я производил на нескольких, оказавшихся под рукой платформах, почти все платформы на Windows 7 x64, другие приложения на время измерений закрывал.

Приложения скомпилированы под х64 платформу. Кроме этого для запуска может потребоваться msvs runtime 2010

Результаты

Ниже приведена таблица с перечнем платформ, на которых запускались измерения и их результатами. В таблице также указана оценка однопоточной производительности платформы (Single Thread Performance) в соответствии с www.cpubenchmark.net.

В дополнение к таблице, хочу добавить что приложения Оffice и например браузер Chrome (на «хороших» страницах) показывают FPS примерно равный FLTK или чуть меньше.

Для более наглядной иллюстрации добавлю график зависимости FPS от оценки Single Thread производительности. График построен на основе данных приведенных в таблице.

График стоит немного прокомментировать. На платформе с оценкой 1000 использовалось низкое вертикальное разрешение экрана, что сильно уменьшило число видимых ячеек, тем самым существенно повысив FPS вертикального скроллирования. Хочу также добавить, что для компиляции FLTK примеров был отключен ряд оптимизаций, поэтому вполне возможно включив их можно несколько увеличить оценки примера FLTK на всех платформах (по этой же причине во время старта примера FLTK появляется окно консоли).

В целом же зависимость FPS от однопоточной производительности процессора достаточно линейна. Есть предположение что многопоточная производительность пока мало применима к UI библиотекам (например, превосходство i7 в многопоточной производительности мало влияет на FPS). Так же измерения показали слабую зависимость FPS в нашем тесте от видеокарты (зависимость безусловно есть, но похоже в данных тестах видеокарта не является узким местом) Еще одной интересной деталью явилось ограничение 30 FPS на ряде платформ. Не уверен связано ли это c драйвером видеокарты или какими-то ее настройками, однако в ряде случаев не удавалось получить более 30 FPS…

Исключительно на основании данных измерений я не могу рекомендовать FLTK, как универсальное средство повышения отзывчивости вашего UI, тем более что писать UI на FLTK весьма трудоемко (на написание FLTK примера у меня ушло около 20ти минут, хотя остальные примеры были написаны заметно быстрее). Однако результаты измерений заставляют задуматься о том, что по многие библиотеки не полностью раскрывают потенциал железа на котором выполняются, делая приложения менее привлекательными для пользователя(с точки зрения отзывчивости по крайней мере).

Буду рад, если подобным образом кто-то протестирует и другие UI библиотеки, предложит вариант оптимизации производительности тестовых примеров (для рассматриваемого случая скроллинга) или же просто расскажет о FPS в тестовых примерах на своей конфигурации.

Как же получить высокий FPS?

Как видно из теста, стабильные 60 FPS, в случае тяжелого UI мы получим разве что на дорогом железе и наиболее затратной в разработке UI библиотеке (то есть дорогим будет и разработка и железо и потребление этого железа), наверное иногда это того стоит, но пока это скорее исключение. Однако, если не вдаваться в крайности и поставить себе целью получить хотя бы 20 FPS в нагруженных информацией интерфейсах. Чего нам это будет стоить?

Для рассмотренных библиотек, вариантов, видимо, не так и много:
1. FLTK + почти самое дешевое железо. На разработку UI мы потратим заметно больше времени, но в текущих ценах сможем сэкономить

100-200$ на железе на рабочее место пользователя.
2. Qt + среднее железо. На железе сэкономить особо не получится, но зато разработка UI будет дешевле чем в случае FLTK. Вероятно в ряде случаев вариант будет оптимальным.
3. WPF + дорогое железо т.е. дополнительные 200-300$ на рабочее место. Ведь если на i7-3770 мы получаем только 12 кадров, то нужно как минимум железо в полтора раза мощнее. Вероятно i7-5930K или возможно i7-4790K в паре с хорошей видеокартой справятся с задачей 20 FPS. Однако вряд ли это будет эффективное решение, да и справятся ли… к сожалению нет такого железа под рукой чтобы проверить, но если экстраполировать однопоточную производительность то ее оценка должна быть свыше 3000, для получения 20 FPS при 1280х1024… такого железа просто не существует, по крайней мере тут.
4. Облегчать UI, до тех пор пока не уложимся в 20 FPS. Например, если используя WPF, вместо 20ти колонок в гриде оставить только 6, то на i7-3770 мы получим стабильные 20 FPS, если же оставить всего 3-4 колонки, то получим 20 FPS и на бюджетном железе. Уменьшение размера самого грида также должно дать положительный эффект (правда на разных библиотеках он разный, и как ни странно для случая WPF эффект наименее выражен). Приемлемы ли такие решения? Применимы далеко не везде, но все-таки покрывают ряд задач, не фокусирующихся на представлении данных.

P.S.: Идея сравнить производительность гридов появилась после того, как я столкнулся с низкой производительностью грида WPF. В комментариях к моей предыдущей статье «Выбор между C++ и C#» я, в частности, разбирал эту проблему.
Далее мне стало интересно, как с задачей отображения грида справляются альтернативные библиотеки, так появились тестовые приложения и результаты изложенные в этой статье.

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