Переход с Windows Forms на WPF ... стоило ли это того?

Question

У меня также есть настольное приложение, написанное на Windows Forms, среднего размера (пара десятков основных форм, подкрепленных 46 таблицами в базе данных). Я думаю о переписывании пользовательского интерфейса в WPF, но перед тем, как отправиться туда, мне было любопытно, есть ли какие-либо военные истории о таком преобразовании.

Я использую LLBLGen для генерации моих низкоуровневых объектов доступа к данным, и у меня есть уровень бизнес-логики выше этого. Формы привязаны к объектам бизнес-логики, хотя основная форма использует объекты кэширования для минимизации циклических переходов по более распространенным маршрутам навигации. Пользовательский интерфейс никогда не обращается напрямую к базе данных: всегда через пользовательский интерфейс -> бизнес-логика -> низкий уровень -> путь к хранилищу данных.

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

Есть ли история, которая может убедить меня пойти дальше и преобразовать (или, наоборот, подождать, пока Microsoft не приблизится к тому, чтобы вытащить коврик из-под Windows Forms)?

РЕДАКТИРОВАТЬ: меня спросили в комментарии, что мотивация для конверсии у меня есть. У меня есть некоторые опасения по поводу проверки будущего: у меня 500 000 строк кода, которые изначально были ASP и VBScript . Со временем мы перенесли эту функциональность на ASP.NET и C #, но только по мере внесения изменений в код. Преимущество в том, что мы минимизировали расходы, недостатком является то, что половина кода остается ASP и VBScript. Меня беспокоит аналогичная ситуация, возникающая с приложениями Windows Forms.

Я беспокоюсь сегодня об исчезновении Windows Forms? Даже не близко к этому ... но приложение переходит с ASP и VBScript на ASP.NET и C #, имеет девятилетнюю историю и, вероятно, не будет заменено в этом десятилетии (вместо этого оно просто будет развиваться). Настольное приложение также является долгосрочным проектом с многолетней историей.

Answer 1

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

Это определенно крутая кривая обучения. Но я НИКОГДА не закончил работу с красивым WPF-приложением и сказал: «Чувак, мне следовало использовать WinForms».

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

Answer 2

WPF имеет смехотворно большую кривую обучения. Скорее всего, вам потребуется переписать намного больше, чем вы думаете, просто изменив пользовательский интерфейс. Кроме того, многие функции, которые сделали бы WPF более привлекательным для использования, еще не реализованы или не включены в WPF. В отличие от routeNpingme , я написал хорошо выглядящие приложения WPF и сказал: «Какая трата времени, я должен был использовать Windows Forms и завершить его на 70% меньше времени».

EDIT: Кроме того, если Microsoft не найдет способ сделать WPF более легким в изучении, я не думаю, что он вообще зацепит массы. WPF может делать очень крутые вещи, но немного усилий, чтобы его было легче понять, вместо того, чтобы бросать вещи через стену, прошли бы долгий путь. Меня не удивило бы, что Microsoft бросит WPF для чего-то более легкого в работе в не столь отдаленном будущем. Так что не меняйте свое приложение Windows Forms просто ради его изменения.

Answer 3

Плюсы:

• Смешно простая привязка данных (в большинстве случаев)
• Смешно простая настройка внешнего вида

Минусы:

• Очень крутая кривая обучения
• Некоторые очевидные ошибки или проблемы. Аналогично .NET 1.0 Windows Forms
• Небольшая или нулевая поддержка инструмента

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

Стоит ли менять приложение на использование WPF сейчас? Нет. Не стесняйтесь изучать WPF, но если ваше приложение работает нормально, то WPF не даст вам ничего лишнего. Это значительно упрощает работу в Windows Forms.

Answer 4

WPF великолепен. Это особенно хорошо для расширения элементов управления, таких как TreeView с настройками. Вы можете добавить строку как элемент в TreeControl. Вы также можете добавить небольшую панель с изображением и текстом различных шрифтов и цветов. Или вы можете добавить кнопки, или все что угодно. Он имеет полностью общую систему компоновки. То же самое касается ListBox, ComboBox, Button и т. Д. Все их содержимое или дочерние элементы могут быть такими же простыми, как строка, или такими же сложными, как просмотрщик многостраничных документов с кнопками масштабирования (если хотите).

Но единственный способ выяснить это - попробовать портировать одну из ваших форм. Не должно быть слишком сложно сделать окно WPF открытым из существующего приложения. Я начал использовать WPF с создания новых панелей с графическим интерфейсом, которые размещались в приложении C ++ Win32. В конце концов было так очевидно, что WPF был подходящим способом, и мы переключили его и сделали внешнюю оболочку WPF, с некоторыми древними диалоговыми окнами, все еще реализованными в старом коде C ++, где мы не могли потрудиться переписать их (вероятно, именно то, что произойдет с Visual Studio 2010).

Answer 5

Я начал вводить элементы WPF в свое приложение WinForms и до сих пор добился большого успеха.

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

Но в приложении есть несколько дополнительных панелей, и большинство из них реализованы с использованием WPF. Итак, я собираюсь на гибрид WinForms и WPF с помощью элемента управления ElementHost.

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

Answer 6

Портирование - сложное решение. Так что просто несколько мыслей, которые помогут вам решить.

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

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

Я даже не рассматриваю WinForms для новой разработки - нет оправдания затрат на настройку.

Answer 7

Основное значение WPF для меня заключается в привязке, а не в интерфейсе кулера. Худший WPF, который я когда-либо видел, это когда люди используют WPF только потому, что он более новый, и вкладывают всю работу в код, за исключением использования связывания. То, что вы получаете, это управление данными WinForms. Поэтому убедитесь, что вы будете использовать замечательную привязку, когда будете делать WPF.

Я бы перенес бизнес-логику ОП на бизнес-уровень для простоты обслуживания и преобразования. Я бы вообще не портировал WinForms на Xaml, если бы не потребовались новые функциональные возможности Xaml, и желательно только после того, как они были перенесены.