Чому WPF живіший за всіх живих?

Я довгий час був розробником систем для десктопа. Спочатку це був WinForms, потім більш потужний і гнучкий WPF. З тих пір пройшло багато часу і курсує безліч чуток і думок про те, що WPF завершує своє життя, адже зараз стільки розмов про те, що можна писати настільні додатки на JS. А ще Microsoft посилено просуває в маси платформу WinRT для розробки нових програм. Це не могло мене і колег залишити байдужим.

Так чому ж ми, команда GoSharp конференції (так, так, це про C#), вирішили зробити акцент на десктопної розробки в розрізі WPF? Далі я хочу показати які світлі і темні моменти є в існуючому положенні фреймворку і чому все-таки варто в нього вкладати сили і час.



Існує думка, що розвиток десктопної розробки зупинилося у своєму розвитку і для цього є кілька передумов. Одна з них — зупинка, або навіть краще сказати стагнація, в самій базі, у візуальному фреймворку WPF. Значних оновлень для нього не було ось вже років 5, як може здатися. Офіційний тулкит давно не оновлювався, точніше з лютого 2010 року, тобто якраз ті самі 5 років. При цьому компанії, що спеціалізуються на кастом-компонентах, як наприклад DevExpress і Telerik успішно випускають оновлення і складають плани на майбутнє щодо WPF. Навіть якщо ви орієнтовані на новинки, то компоненти для WinRT все одно використовують концепції та загальну структуру XAML, який нікуди не йде.
Далі ми хочемо представити причини, за якими WPF деякі вважають неактуальним, і спростування цих причин.


Причини для занепокоєння
Причин для занепокоєння можна виділити з дюжину. Але не всі вони реально так страшні й істотні. Коротко пройдемося по основним.

Блозі команди WPFдавно не оновлювався.

Так само, як і у будь-якої іншої команди, у команди WPF є свій блог, в якому по ідеї повинні бути описані плани і досягнення команди. На жаль, в блозі давно немає нової інформації. Це може наштовхнути на думки, що всіх розігнали або що писати не про що. Однак, це не так і блог став оновлюватися 4 місяці тому і остання запис з'явилася 20 днів тому. Більше того, з'явився генеральний план розвитку фреймворку, а також короткі описи нових фіч доступних з останніми CTP.

Офіційний WPFтулкит давно не оновлювався

Офіційна сторінка WPF Toolkit на CodePlex не оновлювалася з 2010 року. А це ж колись була площадка для обкатки нових компонентів, які відкрито допиливались і в разі успіху вливалися в основні релізи фреймворка. Такий стан справ так само може викликати підозри про те, що нічого нового нам чекати не доводиться і залишиться тільки купувати компоненти у великих компаній або щось робити на коліні, довго і болісно, якщо це не профільний напрям вашої діяльності. Але неофіційний тулкит Extended WPF Toolkit живіший за всіх живих і останній реліз припав на 13 лютого 2015 року. Тобто ось минулого тижня був. Цей тулкит підтримує Xceed, але вкладення йдуть в опенсорс проект, а значить вони бачать майбутнє за ним. Титульний банер однозначно висловлює оптимізм з цього рахунку.



Більше того, звернувшись до одного з найбільших реселерів компонентів, в розділі Best Sellers, можна бачити, що компоненти для WPF входять в топ 5 продажів серед всіх продуктів.

Сертифікація з WPF

В інтернеті можна знайти чутки і повідомлення про те, що основна сертифікація WPF 70-511 закінчується в 2015 році і буде продовжуватися. Це не є правдою, в чому ви можете переконатися особисто, пройшовши за посиланням.

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

Немає інтеграції з Win8+

Під час релізу WPF4, значна частина поліпшень була присвячена інтеграції з Windows 7, проте цього не спостерігається з новими операційними системами. Вже на носі Windows 10, а ніяких нових фіч пов'язаних з можливостями ОС в WPF не спостерігається.

Нова стратегія Microsoft

В лютому 2014 року новим СЕО став Сатья Наділу, який прийшов з «хмарного» департаменту, що може натякати. Сатья замінив Балмера, який не прагнув розвиватися в бік мобільного ринку і хмарних технологій. Можливо в цьому криється причина такого різкого ривка Microsoft в бік мобільного розробки і такого просування Azure. Зараз компанія рухається під гаслом «спочатку хмари і мобільність», що веде до відходу від традиційної моделі настільних додатків і активного використання WPF.

WindowsStore

Публікація WPF додатків Windows Store неможлива. Можна зробити додаток візитку, яка завантажить і встановить повноваге додаток, але це виглядає як обхідний шлях. Однак Microsoft намагається сформувати певний умовний рефлекс, як у Apple і Android користувачів, що всі програми встановлюються тільки через Store. Це так само є деяким дзвіночком не на користь WPF.

Мобільний ринок

Це сутінкова зона для WPF, так як він ніколи не замислювався як засіб для мобільного розробки. Цю роль готували Silverlight for Windows Phone, проте всім відома доля цієї затії. Реалії світу ж зараз такі, що все більша кількість контенту ми споживаємо з допомогою мобільних пристроїв і багато розробляють мобільні версії для основних програм. Якщо це ваш випадок, то швидше за все ви будете використовувати відмінний від WPF стек технологій.

Кросплатформеність

Існування і розвиток Mono дозволяє говорити про деяку кроссплатформенности .NET стека, і для більшості фреймворків є версія під Mono. Проте тільки не для WPF. Хоча недавнє відкриття початкових кодів та ентузіазм у цьому зв'язку налаштовує на те, що WPF все ж може переїхати на Mono і виступати в ролі провайдера користувальницького інтерфейсу.

Багато тривожні міркування нівелюються або скасовуються останніми діями Microsoft. І це дійсно схоже на реальну активність, а не створення видимості активності. До того ж причин скасовувати паніку і продовжувати використовувати WPF більше, ніж негативних моментів.

Позитивні моменти для майбутнього WPF
Активна команда WPF

Команда WPF дійсно прокинулася і їх блог став оновлюватися.

Є потенціал для розробки

Команда WPF працює над поліпшенням швидкодії фреймворку і над підтримкою тач-екранів і екранів з високою щільністю, а це ж характеристики сучасних мобільних девайсів. Підтримка налагодження і профілювання у новій студії. Публікація глобальних планів. Все це вселяє оптимізм. До речі, з цього приводу можна подивитися інтерв'ю на Channel9 про майбутнє WPF.

Нові інструменти

Популярний інструмент Prism, набір інструментів і кращих практик розробки на WPF, оновився до версії 5. Далі, активно розвивається неофіційний розширений набір інструментів для WPF Extended WPF Toolkit, який оновився буквально пару днів тому. У розробці нових інструментів не поступаються і флагмани типу DevExpress.

Два найбільш популярний MVVM фреймворку: MVVM Light Toolkit і Caliburn.Micro так само проявляють активність. Для першого останній чекін датується 21 лютого 2015 року, для другого — 16 березня 2015 року. І це не поодинокі чекіни раз в півроку, а регулярна робота.

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

Зміни в управлінні

В кінці 2012 року Стівен Сінофскі покинув пост President of the Windows Division і Microsoft взагалі. Чому це хороший знак для WPF? Тому що він був відомий як знатний ненависник .NET і погано ладнав з іншими командами. Можливо це і є основна причина його відставки.



Це так само частково може пояснювати, поряд з технічними причинами, чому .Net не був використаний як основний технологічний новий стек для операційних систем Windows, тоді як по факту це один з кращих продуктів Microsoft. Зовні звичайно ж складно оцінити вірність чуток і пліток навколо Стівена і його впливу на те, як вийшли системи Windows 8 і старше.

Інертність ринку ОС

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

Для компаній міграція на нову ОС це завжди головний біль і проблеми. Необхідно переконатися в сумісності всіх сервісів, всіх своїх напрацювань. Переконатися що вендори можуть надати відповідних експертів і підтримку, підготувати свій персонал. Взагалі перехід на нову ОС може становити 2 роки і більше. На цьому тлі виглядає дещо дивним і інтригуючим заяву про те, що кожні 2 роки Microsoft буде випускати нові версії своїх продуктів, включаючи ОС. За прикладом далеко ходити не треба, багато компаній не переходять з сімки на 8 і 8.1 чекаючи, цілком закономірно як справи з новою версією і чи не варто перейти на неї.

На поточний момент розподіл ОС від Microsoft виглядає приблизно так:
  • Windows 8 + 8.1: ~15%
  • Windows 7: ~55%
  • Windows Vista: ~5%
  • Windows XP: ~25%
Тобто більш ніж на 80% машин не доступні функції WinRT і залишається тільки одна опція — WPF. Беручи до уваги, що цикл оновлення ОС і додатків становить близько 5 років, зараз WPF є єдиним вибором, якщо ви вирішуєте зробити додаток не за вихідні і на найближчі півроку.

Інертність ALM

Не багато хто знає, що написати програму коштує чималих грошей. Спочатку в серії зустрічей з усіма зацікавленими сторонами, треба оцінити, який вплив має на поточні процеси у загальному бізнес-процесі. Треба знайти ключових користувачів і переконати їх, що потрібно оновлення. Потім нове треба розробити, при цьому старе повинно працювати як ні в чому не бувало. Новий додаток повинно працювати пліч-о-пліч зі старим, щоб можна було порівняти результати і зрозуміти, що нічого не втрачено і все працює як мінімум на тому ж рівні, не гірше. Так само залучаються хлопці їх DB відділів, щоб попрацювати з бэкапами, інженери мережі, щоб налаштувати нові правила для файрволів і так далі.

І це тільки мала частина всього процесу, але і його вистачає, щоб зрозуміти, що додатків на тільки що з'явилися технологіях ще довго не буде. Підтримка WPF з боку бізнесу буде сильна, тому що це вже стабільна технологія для якої є фахівці і на цьому можна будувати свої процеси. До речі, до цих пір часом потрібні специ по Delphi5 або Fortran для підтримки додатків і вони стоять зараз дуже дорого. Хоча в цілому так далеко ходити не треба, досі актуальні величезна кількість додатків, написаних з використанням WinForms, так що списувати з рахунків WPF було б передчасно.

WPF зріла технологія

Для багатьох розробників очевидно, що перша версія програми забирає найбільшу кількість часу і сил. У такому ключі можна розглядати випуск WPF 3.0 і WPF 3.5. Після перемоги над дитячими болячками, додатки на WPF 4 вже стали «повними», розробники стали приділяти увагу швидкодії, що натякає на стабільність основної технологічної бази. Нарешті у версії 4.5 розробники додали ще прикрас і ще більше підвищили продуктивність.

Чим більш зріла технологія, тим менше трудовитрат вона вимагає. Таким чином після 8 років розробки, підтримка WPF майже не потрібно, що показує зрілість. Але, як я вже писав вище, розробники вирішили не закинули його, а вирішили оживити фреймворк у відповідності з духом часу.

Line of Business (LOB) Application

Локальні бізнес додатка це та сфера в якій WPF не тільки виживе, але в якій домінує і буде показувати себе найкращим чином. Чому?

По-перше, тому що накопичений величезний досвід в розробці додатків на WPF і їх розгортання в системі. Тому що це .Net платформа, яка сама по собі вже зрілий продукт. Якщо компанії мають достатньо додатків .net, то немає ніяких причин зупинятися і переходити на другий стек. Набагато легше використовувати існуючі програмістів для покриття всіх бізнес-потреб. До того ж інтеграція додатків на одній платформі буде істотно легше.

Ще однією причиною, чому WinRT поки не може прийти на зміну WPF — це те, що немає такого ж інструментарію. Наприклад, таких речей як ORM в дусі NHibernate або EntityFramework, які необхідні будь-in-house додатком.

Безпека, для багатьох є наріжним каменем, наприклад у фінансових додатках. Тому використання WinRT може бути не тільки не потрібно, але і не бажано.

Інтеграція з WinForms

За більш ніж 10 років компанії створили величезну кількість додатків на WinForms і переробити їх в один момент за інші технології не представляється можливим. Огроным плюсом в цьому випадку є взаємна між WinForms і WPF можливість використовувати компоненти один одного і впроваджувати один в одного. Таким чином міграція з однієї технології на іншу може відбуватися поступово і відносно безболісно.



Наскільки я знаю, поки що WinRT ніяк не може впроваджуватися в WinForms компоненти, форми.

 

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



Якщо ви так само залучені в розробку з використанням WPF, створюєте складні інтерфейси, працюєте зі складним бізнес-доменом, вас цікавлять питання, пов'язані кращими практиками та тенденціями в десктоп додатках, і ви хочете знайти колег і однодумців, щоб поділитися своєю думкою з приводу всього вищесказаного — ласкаво просимо на конференцію. Нам є про що розповісти один одному!

Якщо більш конкретно, то ми обговоримо теми:
  • Історія користувальницьких інтерфейсів і як зробити UI\UX зручним для корпоративного користувача. Через вікна в хмари.
  • Не створюйте повільних зомбі-додатків. Використовуйте Rx! На реальному прикладі. А також що ви недооцінили в TPL?
  • EF-ом єдиним живі великі програми?
  • Прототипування застосувань
  • Як написати тлумачні UT на користувальницький інтерфейс. Реальний досвід розробки.
  • Холівар на тему повного і анемічного домену
  • І інші захоплюючі історії!
 

Реєструйтеся! До 23 березня діє спеціальна ціна.

 

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.