WPF vs. WinForms - перспектива програміста Delphi?


38

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

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

З огляду на це, я сподіваюся, що ті з вас, хто перейшов з Delphi на C #, можуть допомогти мені у моєму рішенні WinForms проти WPF для написання моїх початкових заявок. Зауважте, я дуже нетерплячий, коли кодування та такі речі, як повноцінна автоматична заповнення та належна підтримка налагодження, можуть зробити або порушити проект для мене, включаючи можливість пошуку доступної інформації про функції API та дзвінки, а ще більше - обхідні проблеми для помилок .

Нитки та коментарі на початку 2009 року викликають велике занепокоєння щодо WPF, коли мова заходить про можливі розлади, які можуть пошкодити моє кодування розробки C # UI. З іншого боку, витратити непотрібну кількість часу на вивчення технології API, яка, навіть якщо вона не відмовилася, незабаром її замінити (WinForms), є однаковою проблемою, і я знаходжу підтримку GPU у зануренні WPF.

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

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


2
Чи не має WPF по-справжньому погану репутацію за низьку продуктивність?
Девід Геффернан

9
@David: Це дійсно така репутація, але, як завжди, реальність не така вже й погана, як реп. Графічний інтерфейс Visual Studio 2010 був переписаний на WPF, і на більшості машин не спостерігається помітного зниження швидкості порівняно з VS 2008. @Robert: Враховуючи це, моя рекомендація дуже б на користь WinForms, особливо для конвертатора Delphi. Але я трохи не вагаюся, як це відповісти, щоб уникнути її забуття. Кожен, здається, проти цього схильний, бо це "стара" технологія, ніби це насправді щось означає.
Коді Грей

@Cody. Зрозумів. Я отримую чудову інформацію з відповідями та коментарями, але сподіваюся на більш пряму інформацію про WPF та підтримку налагоджувача порівняно з WinForms та деякою інформацією про ринок роботи. Відповіді на мої запити в цих тематичних областях все ще хочеться.
Роберт Ошлер

1
@CodyGray: Ви мусите жартувати. VS2010 в сто разів повільніше, ніж VS2008, і WPF. Ваше враження, ймовірно, пов’язане із звичним упередженням програміста: ви дивитесь лише на останні версії високого класу, яких у більшості звичайних користувачів немає.
Тімві

Відповіді:


21

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

Наприклад, ось лише кілька обмежень WinForms, з якими ми стикаємося:

  • У WinForms немає нічого подібного до TAction, тому якщо ви звикли кодувати дії, обмінюватися тим самим текстом та піктограмою між пунктом меню та кнопкою на панелі інструментів та меню правою кнопкою миші, централізуючи свою логіку ввімкнення та оновлюючи включений стан у фоновому режимі з OnUpdate ... ви будете ненавидіти WinForms, де вам потрібно зробити все, що важкий і схильний до помилок спосіб.
  • Стара версія (.NET 1.0 vintage) WinForms не підтримує зображення поруч із пунктами меню, а новий (представлений у .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.


1
Дякуємо за прямий коментар Delphi. Будь-які коментарі на ринку праці та будь-яка інформація щодо підтримки налагодження VS 2010 для WPF, особливо проблеми з відстеженням та інспекцією? Я перевірю книгу, з якою ви пов’язані.
Роберт Ошлер

1
Не знаю про ринок праці. Що стосується налагоджувача, очікуйте розчарування, якщо конструктор вашого вікна викине виняток, тому що налагоджувач буде неохоче давати вам стежку стека - але все, що вам потрібно зробити, це перекопатись на два рівні InnerException у діалоговому вікні винятків-деталі виправлення. І якщо ваші прив’язки не працюють, запустіть під налагоджувачем і подивіться у вікні виводу, щоб побачити помилки прив'язки. Крім цього, я не впевнений, що стосується вас. На моєму досвіді WPF налагоджує ОК, і MVVM дозволяє вам перевірити більше логіки інтерфейсу, ніж ви можете в WinForms.
Джо Уайт

6
Дуже крута крива навчання. Вам не так багато програми у WPF; ви задаєте питання, як переконати WPF робити те, що ви хочете.
Ян Бойд

Насправді, деякі з найбільших перешкод полягають у тому, щоб навчитися працювати з рамкою, яка належним чином розділяє обов'язки, а не просто з усіма сліпо випливати з TKitchenSink.
Джо Вайт

1
Чи можу я мати форми Delphi, але зберігати мову C #? Будь ласка?
Роберт Харві

13

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

Інше, що мене турбує - це те, як люди зазвичай асоціюють WPF лише з інтерфейсом користувача. Це дійсно в 100 разів краще, ніж WinForms, на мій погляд, завдяки простоті дизайну інтерфейсу, але є багато інших причин, які вам сподобається використовувати WPF:

  1. UI, звичайно.
  2. В'язки. Просто звичайна магія. Найпотужніша функція після інтерфейсу користувача. Програми LOB отримують найбільше користь від цього.
  3. Команди.
  4. Розділення проблем. Дизайнери працюють над дизайном, програмістами програми.
  5. Приєднані властивості. Ви можете розширити функціонал сторонніх елементів керування без вихідного коду (хоча ця точка цілком може бути частиною першої точки).
  6. Легкий перехід на Silverlight (І Інтернет, і WP7)

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

І найбільша причина - це майбутнє. Він може бути об'єднаний із Silverlight, але навички залишаться тими ж.

Отже, я настійно раджу вам пройти шлях WPF.


1
Я не кажу, що я не згоден, але всі ці причини пов'язані з інтерфейсом користувача (хоча ви кажете, що інша річ, яка мене турбує, - це те, як люди зазвичай асоціюють WPF лише з інтерфейсом )
Ed S.

1
+1, оскільки я згоден з усіма вашими пунктами. Мені потрібно вибрати, якщо я хотів вивчити WPF або Winforms, і я обираю WPF і ніколи не шкодував про це. @Ed: Я не бачу жодного з них, що стосується суто інтерфейсу користувача, крім першого.
Рейчел

1
@Rachel: Дійсно? Прив'язка використовується для оновлення інтерфейсу користувача, коли змінюється значення властивості. Розділення проблем у №4, очевидно, стосується лише розробки інтерфейсу користувача. №5 - це все про управління сторонніми сторонами. Ні інтерфейсу, ні контролю. №6 - це знову все, що стосується перекладу на інтерфейс Silverlight. Я щось пропускаю?
Ред С.

3
Я більш-менш пішов навпаки: WPF -> WinForms -> C ++ / MFC. Так, я бунтівник; Я плаваю вгору за течією. Я просто не бачу нічого переконливого в тому, що WPF приносить користувальницькому інтерфейсу. Купа жахливого, нероднього програмного забезпечення - це не моя ідея "прогресу". Крім того, я не впевнений, як структури дизайну, які так багато (включаючи цю відповідь) асоціюються з WPF, якимось чином виключно для WPF. Ви можете використовувати шаблони дизайну на будь-якій мові чи графічному інтерфейсі. Чи різниця просто в тому, що якщо тебе не змушують , люди не стануть? Простота переходу до Silverlight - це єдина переконлива причина.
Коді Грей

5
Моє перше завдання з додатком WPF: скиньте панель інструментів, зробіть її в 14 длус заввишки. зробити це неможливо . Друге завдання: встановити шрифт форми відповідно до розміру та розміру шрифту користувача. неможливо зробити Третій крок: додавання елементів до перегляду списку без прив'язки неможливо зробити, я вийшов.
Ян Бойд

5

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

Кілька порад:

  • Почніть легко: не намагайтеся реалізувати свій перший проект, використовуючи лише MVVM або фантазійні анімації. Почніть просто з вікон, кнопок та списків.
  • Скористайтеся перевагами DataBinding.
  • Придбайте книгу WPF, розв'язану Адамом Натаном.

+1. Практична відповідь. Спробуйте не реалізовувати свій перший проект, використовуючи лише MVVM або фантазійні анімації
Karthik Sreenivasan

4

Спершу слід зазначити, що я здебільшого розробник asp.net, хоча раніше я багато використовував. Перехід на WPF не такий великий, як ви робите це (imo) через тиждень або близько того (40+ годин), більшість знову було другою природою.

У будь-якому разі я вважаю, що Андерс Хейльсберг є одним із архітекторів, що стоять за WPF, принаймні за даними видавців цієї книги->

" Як один з архітекторів, що стоять за WPF, Кріс Андерсон майстерно пояснює не тільки" як ", але і" чому ". Ця книга є чудовим ресурсом для всіх, хто хоче зрозуміти принципи проектування та найкращі практики WPF. - Андерс Хейльсберг, технічний співробітник корпорації Microsoft

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


11
"Як один з архітекторів, що стоять за WPF, Кріс Андерсон майстерно пояснює ..." припускає, що Кріс Андерсон є одним з архітекторів, що стоять за WPF. Андер Хейлсберг є лише "технічним співробітником" корпорації Майкрософт, згідно з цитованим текстом, що, таким чином, не підтверджує його причетність до WPF.
Андреас Рейбранд

Так, це може бути правдою, але це показує, що він це поважає!

2
Або принаймні, що він поважає Кріса.
Брюс Макгі

1
Або принаймні, що PR-відділ змусив когось із репутацією зробити коментар.
quick_now

@Andreas; Гарний жарт: тільки "технічний хлопець". Не бажаючи зменшувати Кріса Андерсона - він чудовий хлопець, який тримає трохи низький профіль ( msdn.microsoft.com/en-us/ff395959 є, але simplegeek.com давно не оновлювався). Андерс Хейльсберг бере участь у багатьох .NET-речах (технічні стипендії мають широке охоплення), адже він - хлопець з рамки (VCL, WCF тощо) - див. Simple-talk.com/content/article.aspx?article=673 та microsoft .com / presspass / exec / techfellow / Hejlsberg / default.mspx ) і є лише кілька технічних співробітників ...
Jeroen Wiert Pluimers

2

Winforms майже майже ідентичний розробці Delphi. І, звичайно, в цьому є причина. Так само, як об'єктна модель Delphi / Object Pascal сильно вплинула на C #, так система форм вплинула на Winforms.

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

Якщо ви хочете залишитися у вашій зоні комфорту, займіться формою winform. Якщо ви хочете потрапити в новітнє та найкраще місце, зануріться у WPF.


3
WinForms - це те, що Delphi розширює, насправді це дуже неприємно порівняно з Delphi. Він більше схожий на VB-3, ніж на Delphi, і рівень IME фрутрації схожий.

2

Я не програміст Delphi, але так, я працював як на WinForm (сильно), так і на WPF (менше, ніж в середньому). Я певною мірою погоджуюся з вами щодо рівня фрустрації того, хто переходив би з WinForm на WPF, оскільки я був у цій ситуації, але лише до того моменту, коли я звик до цього. Дізнайтеся і подивіться, наскільки чудовим та гнучким є WPF порівняно з WinForm. Він має важку криву навчання, принаймні для того, хто походить із Delphi, а не Winform. Для вас, безумовно, варто рухатися до WPF, а не до WinForm, і варто того часу.

Ви можете переглянути посилання нижче для початку:


1

Я робив деякі роботи з Windows Forms (в основному на кишенькових ПК), а також інше середовище, яке не є .NET, яке використовувало ті самі принципи. Коли я перейшов на WPF близько трьох років тому, перші кілька місяців я присягав на це. Врешті-решт він просто "клацнув", і я не озирнувся назад - насправді я зіткнувся б, якщо наступний проект вимагає від мене повернення до Windows Forms.

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

Підсумок: Існує крута крива навчання, і я все ще її вчу. Але це все було того варте. Це дуже весело.


1

Якщо ви збираєтеся писати нові програми з нуля, використання WinForms було б помилкою. Він в основному мертвий з точки зору інвестицій. Microsoft буде тримати це довгий час, але ви не отримаєте жодних нових функцій або нової підтримки і т.д.

З точки зору кар'єри, ви також набагато краще знаєте WPF проти WinForms. З цих же причин вище. Крім того, у вас буде гарна нога в навчанні Silverlight. Між цими двома платформами існує перекриття.

І нарешті, WPF просто веселіше. І більш потужний.

Крива навчання крутіша, я даю вам це. Але це зрештою корисніше.


0

Одним із додаткових міркувань, які слід зазначити, є те, що не існує плану підтримки монографії WPF . Я усвідомлюю, що ви не виявляли інтересу до (моно) кросплатформної підтримки, але можливо, для цього буде можливість у майбутньому (якщо ви їдете з Winforms). Імовірно, підтримка WPF в моно (або подібному) буде мати місце.

редагувати: Як я вказав на посилання, і коментар Гульшана підкреслив, Moonlight - це спроба з відкритим кодом, яку очолює монокоманда з надання міжплатформової підтримки Silverlight .


Але Місячне світло знаходиться в активному розвитку.
Гульшан

-1

Я був схвильований, коли почув про 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, але я також думаю, що це займе більше часу для створення, і ви будете сильно стукати головою по дорозі.


"Я думаю, що ваша заявка, безсумнівно, виглядатиме / почуватиметься краще у WPF". Не обов’язково - WPF не врятує вас від написання неправдивого інтерфейсу. У мене є декілька прикладів (один з яких мій, хоча цей був просто швидким "n 'брудним додатком для випробування деяких речей"). Якщо ви (і ті, хто дзвонить у кадри, він же $$) готові витратити час і зусилля, ви можете зробити дивовижні речі в WPF.
MetalMikester

Справедливий пункт. Я мав на увазі те, що WPF дозволяє створити гарніший додаток, оскільки ви менше обмежуєтесь віджетами Windows. Звичайно, це може бути і хорошою, і поганою справою!
Danny Tuppeny

3
Однозначно погана річ. WPF запровадив епоху абсолютно не рідних інтерфейсів. Складно зрозуміти і ще складніше подивитися. Те, що одна людина вважає прекрасним, - це найгірший кошмар людини. Залишити "скин" на вбудовані елементи управління ОС - фантастичний спосіб зробити всіх щасливими. Потім я знову відмовляюся від використання останніх версій Office, оскільки не витримую інтерфейс. Отже, знаєте, зійдіть з моєї галявини та ін.
Коді Грей

1
Я б сказав, що це трохи суб’єктивно. Я, мабуть, не хотів би, щоб мій Word Pocessor порушив усі ці правила, але деякі програми можуть уникнути цього. Напр. Одним з найкращих зразків WPF, який я пам'ятаю, був Yahoo - для мене це велике вдосконалення для додатка на основі віджетів для Windows: blogs.msdn.com/cfs-filesystemfile.ashx/__key/…
Danny Tuppeny
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.