WPF против WinForms - взгляд программиста на Delphi?

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

Я многолетний программист на Delphi, который, наконец, делает прыжок на C #. Мои коллеги-программисты на Delphi поймут, что мне очень приятно узнать, что Андерс Хейлсберг, известный в Delphi, был архитектором C #. У меня сильная зависимость от пользовательских компонентов VCL Delphi, особенно тех, которые участвуют в создании многошаговых мастеров и компонентов, которые действуют как контейнер для дочерних компонентов.

Исходя из этого, я надеюсь, что те из вас, кто перешел с Delphi на C #, могут помочь мне с решением WinForms vs. WPF для написания моих первоначальных приложений. Обратите внимание, я очень нетерпелив, когда кодирование и такие вещи, как полноценное автоматическое заполнение и правильная поддержка отладчика, могут создать или разрушить проект для меня, включая возможность находить легкодоступную информацию о функциях и вызовах API и, тем более, обходные пути для ошибок. ,

Потоки SO и комментарии в начале 2009 года вызывают у меня большую озабоченность по поводу WPF, когда дело доходит до потенциальных разочарований, которые могут испортить мой код разработки на C # UI. С другой стороны, тратить слишком много времени на изучение технологии API, которая, даже если она не будет заброшена, скоро будет заменена (WinForms), также вызывает беспокойство, и я действительно нахожу поддержку GPU в WPF.

Отсюда и моя двойственность. Так как я еще не изучил ни одну технологию, у меня есть редкая возможность начать все сначала, и мне не нужно сталкиваться с большой кривой «отученности», которую я видел, как люди упоминали в различных потоках, когда программист WinForms переходит на WPF. С другой стороны, если использование WPF будет слишком неприятным или будет иметь другие серьезные негативные последствия для нетерпеливого разработчика RAD, такого как я, я просто буду придерживаться WinForms, пока WPF не достигнет того же уровня поддержки и простоты использования. Чтобы дать вам конкретный пример моей психологии как программиста, я использовал VB и впоследствии Delphi, чтобы полностью избежать реальной боли в кодировании с помощью MFC, библиотеки пользовательского интерфейса Windows, с которой многие разработчики столкнулись при разработке ранних приложений для Windows. Я никогда не сожалел о своей удаче избежать MFC.

Также было бы приятно узнать, приложил ли Андерс Хейлсберг руку к архитектуре WPF и / или WinForms и есть ли какие-либо различия в креативном видении и простоте использования, воплощенных в любой кодовой базе. Наконец, снова для программистов на Delphi, дайте мне знать, сколько "IDE schock" я испытываю при использовании WPF, в отличие от WinForms, особенно когда речь идет о поддержке отладчика. Любые комментарии рынка труда, обновленные за 2011 год, также будут оценены.

Если у вас есть опыт работы с Delphi, вы будете разочарованы в WinForms. Вы будете пытаться делать вещи, которые были просты в VCL, только чтобы обнаружить, что они мучительно трудны или даже невозможны. WPF будет намного менее ограничен.

Например, вот лишь некоторые из ограничений WinForms, с которыми мы столкнулись:

• WinForms не имеет ничего, что можно сравнить с TAction, поэтому, если вы привыкли кодировать с помощью действий, совместно использовать один и тот же текст и значок между элементом меню и кнопкой панели инструментов и меню, вызываемым правой кнопкой мыши, централизуя логику включения и обновляя включенное состояние в фоновом режиме с OnUpdate ... вы будете ненавидеть WinForms, где вы должны делать все это жестким и подверженным ошибкам способом.
• Старый WinForms (.NET 1.0 vintage) MainMenu не поддерживает изображения рядом с пунктами меню, а новый (представленный в .NET 2.0) MenuStrip пронизан ошибками, которые Microsoft отказывается исправлять (поскольку исправления могут нарушать обратную совместимость).
• Многие элементы управления, например TreeView, крайне недооценены по сравнению со своими аналогами VCL (крайне медленно, нет рисования владельца, отсутствуют многие параметры настройки и т. Д.)
• Нет ничего похожего на динамичное сообщество сторонних разработчиков элементов управления, к которому вы привыкли в Delphi. Существуют библиотеки контроля качества, но вы платите за них - бесплатных предложений, таких как VirtualTreeView, просто нет для WinForms.

WPF в некотором отношении немного более скромен, чем WinForms, но он гораздо более расширяем.

• Вы хотите что-то вроде TAction? В WPF есть ICommand, который так же богат, как вы привыкли (но обязательно прочитайте статью Джоша Смита о MVVM - обычно вам нужно вручную включать / отключать команды при изменении состояния, но его версия автоматически запускает ваш код включения в фоновом режиме, как вы привыкли с OnUpdate).
• Вы хотите изображения в меню? Это встроено (и нигде не так глючит, как в WinForms).
• WinForms исключает рисование владельцем некоторых важных элементов управления, но если вы вместо этого используете WPF, вам не нужно рисовать владельца - если вы хотите, чтобы на узлах TreeView был черный текст, за которым в круглых скобках следует синий номер, вы просто поместите его в свой DataTemplate, и он будет работать, без уродливого кода для рисования владельцем.
• Вы хотите сторонний контроль? Во многих случаях они вам не нужны, потому что вы можете расширить то, что есть, способами WinForms и, да, разработчики VCL могут только мечтать.

У WPF очень крутая кривая обучения, но если вы выберете хорошую книгу (например, « WPF 4 Unleashed »), это поможет вам преодолеть худшее из этого - и вы будете рады работать с фреймворком, который не будет сдерживать вас так, как это сделает WinForms.

Я обычно очень удивляюсь, когда люди говорят, что у них не было хорошего опыта работы с WPF. Я разработчик, который перешел с C ++ / MFC на C # / WinForms на C # / WPF. Переход от WinForms к WPF был непростым, потому что изучение XAML не очень легко, но как только вы его освоите, это потрясающая технология. Я, например, не могу вернуться к WinForms. WPF просто потрясающий.

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

1. Интерфейс, конечно.
2. Наручники. Просто волшебство. Самая мощная функция после пользовательского интерфейса. Приложения LOB извлекают из этого наибольшую выгоду.
3. Команды.
4. Разделение проблем. Дизайнеры работают над дизайном, программисты программируют.
5. Прикрепленные свойства. Вы можете расширить функциональность сторонних элементов управления без исходного кода (хотя этот пункт вполне может быть частью первого пункта).
6. Простой переход на Silverlight (как веб, так и WP7)

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

И главная причина в том, что это будущее. Он может быть объединен с Silverlight, но навыки останутся прежними.

Итак, я настоятельно советую вам пойти по пути WPF.

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

Несколько советов:

• Начните легко: не пытайтесь реализовать свой первый проект, используя только MVVM или модную анимацию. Начните с простых окон, кнопок и списков.
• Воспользуйтесь преимуществами DataBinding.
• Купить книгу WPF Unleashed от Адама Натана.

Прежде всего я должен отметить, что я в основном разработчик asp.net, хотя раньше я использовал winforms много. Переключение на WPF не так велико, как вы делаете (IMO) через неделю или около того (более 40 часов), большинство из них снова стало второй натурой.

В любом случае, я считаю, что Андерс Хейлсберг является одним из архитекторов WPF, по крайней мере, по мнению издателей этой книги->

« Как один из архитекторов WPF, Крис Андерсон умело объясняет не только« как », но и« почему ». Эта книга является отличным ресурсом для всех, кто хочет понять принципы дизайна и лучшие практики WPF. Андерс Хейлсберг, технический сотрудник корпорации Microsoft

http://www.amazon.com/Essential-Windows-Presentation-Foundation-WPF/dp/0321374479

Winforms практически идентичны разработке Delphi. И, конечно, есть причина для этого. Как объектная модель Delphi / Object Pascal сильно повлияла на C #, так и система форм повлияла на Winforms.

WPF, кажется, направление, в котором все движется; Говорят, что (великолепно!) пользовательский интерфейс VS2010 основан на WPF, в отличие от предыдущих поколений, основанных на Winforms.

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

Я не программист на Delphi, но да, я работал как с WinForm (интенсивно), так и с WPF (менее чем умеренно). Я в некоторой степени согласен с вами в том, что касается уровня разочарования для кого-то, кто будет переходить с WinForm на WPF, поскольку я сам нахожусь в такой ситуации, но только до тех пор, пока я к этому не привыкну. Узнайте, как замечательно и гибко работать с WPF по сравнению с WinForm. У него тяжелая кривая обучения, по крайней мере, для тех, кто пришел из Delphi, а не из Winform. Для вас, безусловно, стоит перейти к WPF, а не к WinForm, и оно того стоит.

Вы можете посмотреть ссылки ниже, чтобы начать с:

• http://drwpf.com/blog/
• http://www.wpftutorial.net/
• http://joshsmithonwpf.wordpress.com/

Я выполнил некоторую работу в Windows Forms (в основном на Pocket PC), а также в другой среде, отличной от .NET, в которой использовались те же принципы. Когда я перешел в WPF около трех лет назад, первые несколько месяцев я ругался на это. В конце концов, это просто «щелкнуло», и я не оглядывался назад - на самом деле я был бы огорчен, если бы мой следующий проект потребовал, чтобы я вернулся к Windows Forms.

Последний раз Windows Forms обновлялся в 2005 году (VS 2005.) Он все еще там, но уже не улучшается Microsoft. WPF - новичок в области настольных приложений, поэтому, если вы собираетесь перейти на платформу .NET с помощью инструментов MS, я бы сказал, что это безопасная ставка. Некоторые люди выдвигают Silverlight в качестве настольного решения, но когда я посмотрел на него как на возможность, я обнаружил, что у него слишком много ограничений (что может иметь смысл в веб-контексте, но не на настольном компьютере).

Итог: есть крутая кривая обучения, и я все еще изучаю ее. Но это того стоило. Это очень весело.

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

С точки зрения карьеры, вам также гораздо лучше знать WPF против WinForms. По тем же причинам, что и выше. Кроме того, вы хорошо освоите Silverlight. Между этими двумя платформами существует масса совпадений.

И, наконец, WPF просто веселее. И более мощный.

Кривая обучения круче, я даю вам это. Но это более полезно в конце.

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

edit: Как указывалось в приведенной мной ссылке и выделен комментарий Гулшана, Moonlight - это проект с открытым исходным кодом, возглавляемый командой разработчиков mono для обеспечения кроссплатформенной поддержки Silverlight .

Я был взволнован, когда услышал о WPF, идея звучала великолепно, и все, что я видел, было прекрасным. Однако, когда я пришел использовать его в Visual Studio 2008 (по общему признанию, бета-версия), я обнаружил, что работать в конструкторе / IDE сложно и странно.

В то время я опубликовал небольшую информацию в своем блоге:
http://blog.dantup.com/2007/08/visual-studio-2008-beta-2-first.html
http://blog.dantup.com/2007 /08/wpf-designer-cider-part-2.html

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

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