Подтвердить что ты не робот

Миграция из Windows Forms в WPF... Стоит ли это того?

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

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

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

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

EDIT: меня спросили в комментарии, какая мотивация для конверсии у меня есть. Я беспокоюсь о будущей проверке: у меня есть 500 000 строк кода, которые первоначально были ASP и VBScript. Мы переносили функциональность с течением времени на ASP.NET и С#, но только по мере внесения изменений в код. Положительный результат заключается в том, что мы минимизировали издержки, недостатком является половина кода, который остается ASP и VBScript. Меня беспокоит аналогичная ситуация, возникающая в приложениях Windows Forms.

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

Плюсы:

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

Минусы:

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

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

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

Ответ 5

Портирование - это трудное решение. Вот только некоторые мысли, которые помогут вам решить.

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

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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