GeekFamily
Компания
27,33
рейтинг
18 марта 2015 в 07:40

Разработка → Почему 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.

Windows Store

Публикация 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 марта действует специальная цена.

 
Автор: @VioletTape
GeekFamily
рейтинг 27,33
Компания прекратила активность на сайте

Комментарии (64)

  • +7
    Потому что вариантов других нету :) WinForms? XWT? Gtk#?…
    • +1
      Для Store/Win Phone есть JS. Учитывая любовь индусов к JS, Сатья сделает его же и для всего остального.
  • +2
    WPF — сейчас фактически единственный инструмент для настольных корпоративных решений для ОС Windows

    З.Ы. Эх, ну почему 11 апреля? Ну не могу я в свой день рождения работать =)
    • 0
      Если работать не хочется ради прикола, что бы размять мозги можно пройти симуляцию теста: onlinetestcentre.com/70-511.html
      Иногда обнаруживаются пробелы, в общем штука интересная.
  • +13
    ИМХО, WPF обречен не стать популярным. А потому и загнётся со временем.

    Обосновываю:
    WPF по своей сути — WinForms 2.0. Т.е. по-прежнему не самостоятельная изолированная технология, а обёртка, сильно завязанная на конкретные OS API. Отсюда и непереносимость (отсутствие в Mono).
    То, что телерик продолжает писать дополнения — а что ему ещё делать? Да, пишет, да мы на подписке пользуемся. Но оно как тормозило 3-4 года назад, так и тормозит, если делать что-то посложнее Hello World. Всё, что мы можем сделать — это выбрать момент, когда оно затормозит (имею в виду ситуацию с табами — или всё тупит, когда создаётся TabControl или всё тупит, когда ты переключаешь табы).

    То, что MS давно болт забило на WPF, говорит хотя бы то, что оптимизированные Binding пишет простой народ, а не они. MS лишь докручивает совместимость (что и видно из логов).

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

    Silverlight. В своё время я, владея, SL нашёл отличную работу. Но он дошёл до максимальной совместимости с WPF и тоже загибается.

    Многие вещи мне, как программисту в WPF нравятся. DataTemplates, Styles, DataTriggers. То, что MS & свободные разработчики предложили подходящий MVVM под это дело(хотя оно и с костылями, типа Behavior).

    Но будущего, без плотной поддержки и доработки быстродействия и портирования от MS я у WPF не вижу.
    Вот отвязали же они ASP.NET от IIS. А с WPF так не поступили. С
    мотрите на их реальные поступки и не вляпайтесь.
    • +3
      К сожалению, не могу не согласиться. Мне тоже кажется, что у WPF нет будущего. Да и жив он только благодаря огромной инерционности ОС и корпоративных приложений.
      Делаю ставку на WinRT (C# или JS, и то и другое будет популярным). Мне кажется его популярность вырастет очень сильно после перехода на Windows 10, где можно запускать WinRT приложения в обычных окнах.
      • 0
        Тут прошла какая-то странная противоречивая новость, что WinRT умер.
        • +1
          Вы путаете версию Windows RT (продолжение которой не будет), с фреймворком, который составляет основу современного интерфейса — Windows Runtime (позволяя создавать так называемые универсальные приложения — Universal Apps).
          • 0
            А вы под WinRT имели ввиду Runtime? Я знаю разницу, ничего не путаю :)
    • +2
      Увы, это правда. Даже жалко времени, потраченного на XAML related технологии (wpf, sl, wp8, win8). Прошло много лет — ничего не поменялось.
      2015ый год, чтобы забиндить !IsBusy на IsEnabled мы пишем:
      "{Binding IsBusy, Converter={StaticResource InverseBooleanConverter}}"
      

      SL мёртв (даже презентации МС проводит во флеше), WPF жив старыми ентерпрайзоными проектами, WP8 имеет долю в пару процентов в мире. Win8 приложения вообще никому не нужны.
      Опять ждать/надеятся на Вин10, как ждали вп8+вин8… нет сил.
      Как не прискорбно, но будущее видется за js.
      • 0
        Хм, а если применить DataTrigger?
        Хотя, в любом случае, громоздко выходит для такой простой операции.
        • +1
          Во-первых, более громоздко, да. Во-вторых, в WP8/Win8 даже дататриггеры не завезли.
          Кстати, в том же Android+MvvmCross такой биндинг бы выглядел так:
          local:MvxBind="Enabled Inverse(IsBusy)"
          
      • +1
        Это из коробки. Но при этом там вполне хватает хуков для того, чтобы реализовать вот такое:
        <Menu IsEnabled="{Binding Loading, Converter={wpf:Lambda '(bool x) => !x'}}" ...
        

        (Кому интересно, покопайтесь здесь и здесь)
        • 0
          Выглядит интересно, но нет нативной поддержки — не type safe (переименовки, подсказчик при написании лямбды).
          И вопрос перфоманса интересует, используется GenerateCodeFromCompileUnit (а wpf и так медленный).
          На мобильном XAML (wp8, win8) такое и работать в принципе не будет.
          • 0
            Да, это, разумеется, WPF. Его «наследники» намного более убоги.

            Насчет нативной поддержки редактирования (это все-таки не то же самое, что type safe) — ну так её нет и у обычных биндингов. Хотя это в принципе можно сделать, возможности редактора VS такое позволяют — аналогично тому, как в ASP.NET редактор поддерживает смешанный HTML и C# код.

            На производительность генерация кода не влияет, так как происходит целиком на этапе компиляции — обратите внимание, это MSBuild-таск. По сути он вклеивается в обычный пайплайн для генерации кода для WPF, и вшивает тело лямбд в partial class. Потому и все ошибки в лямбде, будь то неверные типы или переменные, вылезут на этапе компиляции (ну, если вы не используете dynamic — а по умолчанию, если не указать тип параметра у лямбды, то он там будет именно dynamic).

            Производительность в рантайме — один словарный поиск по строке для каждой лямбды один раз при загрузке XAML, плюс два косвенных вызова на каждый вызов лямбды (там несколько оберток). По сравнению с накладными расходами на сам биндинг, вы это вообще не заметите.
            • 0
              Интересное решение, спасибо за объяснение. Давно не использовал WPF. Но все равно биндинг немного монструозненько выглядит для такой простой операции.
            • 0
              Насчет нативной поддержки редактирования (это все-таки не то же самое, что type safe) — ну так её нет и у обычных биндингов.
              Тут вы не совсем правы. Если в xaml объявить тип DataContext (d:DataContext), то студия будет подсказывать свойства при написании Binding.
              • 0
                и даже без DataContext, решарпер (будем считать, что это нативная поддеркжа) будет следить за тем, что бы биндинги тоже переименовывались после переименовки свойств во вьюмодели.
              • 0
                и даже без DataContext, решарпер (будем считать, что это нативная поддеркжа) будет следить за тем, что бы биндинги тоже переименовывались после переименовки свойств во вьюмодели.
    • 0
      Не могу согласиться, отличий от WinForms настолько много, что непонятно как вообще можно их сравнивать (да тот же отказ от GDI/GDI+).
      Да, у привязок есть ограничений, но достаточно написать несколько своих хелперов (или взять готовые), чтобы стало комфортно.
      По быстродействию возможно вы правы, я не вывожу в списки больше 500 элементов, к тому же есть пейджинг, на моих объемах тормозов не видел.
      Если учесть направления в которых сейчас развивается Microsoft, то что они внесли линукс в список поддерживаемых систем, то, вполне вероятно, скоро мы увидим и кроссплатформенный WPF.
      • +3
        Главная проблема WPF вовсе не в его архитектуре и идеях — о том что они хорошие никто не спорит — главная проблема в том что уже почти 8 лет он никак не развивается.

        И есть проблемы гораздо серьезнее кроссплатформенности — начиная с синтаксиса (где Razor для WPF?) и не заканчивая кривым движком рендеринга, из-за за которого даже HTML в браузере временами работает быстрее (повторю комментарий ниже — подробное исследование и опыт Evernote которые ради повышения производительности переехали на Chromium Embedded Framework).

        Конечно было бы очень хорошо если бы на него снова обратили внимание и начали так же активно развивать, как ASP.NET.
        • 0
          > где Razor для WPF?

          А что вы в MVVM хотите делать с Razor?
          • +1
            В соседнем комментарии уже цитировали статью на эту тему Семь лет WPF: что изменилось?:

            Вот как в далёком 2006-м году выглядела разметка относительно простого окошка (код позаимствован из проекта, над которым я тогда работал):

                <Window x:Class="PaulStovell.TrialBalance.UserInterface.MainWindow"
                  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                  xmlns:tb="clr-namespace:PaulStovell.TrialBalance.UserInterface"
                  xmlns:tbp="clr-namespace:PaulStovell.TrialBalance.UserInterface.Providers"
                  xmlns:system="clr-namespace:System;assembly=mscorlib"
                  Title="TrialBalance" 
                  WindowState="Maximized"
                  Width="1000"
                  Height="700"
                  Icon="{StaticResource Image_ApplicationIcon}"
                  Background="{StaticResource Brush_DefaultWindowBackground}"
                  x:Name="_this">
            


            Только взгляните на все церемонии! x:Class! Пространства имён XML! Почему бы не объявить всё это в одном месте, почему бы стандартные пространства имён не включать неявно?

            К счастью, сейчас 2013-й год, и WPF был проделан огромный путь. Вот так код будет выглядеть сегодня:
                <Window x:Class="PaulStovell.TrialBalance.UserInterface.MainWindow"
                  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                  xmlns:tb="clr-namespace:PaulStovell.TrialBalance.UserInterface"
                  xmlns:tbp="clr-namespace:PaulStovell.TrialBalance.UserInterface.Providers"
                  xmlns:system="clr-namespace:System;assembly=mscorlib"
                  Title="TrialBalance" 
                  WindowState="Maximized"
                  Width="1000"
                  Height="700"
                  Icon="{StaticResource Image_ApplicationIcon}"
                  Background="{StaticResource Brush_DefaultWindowBackground}"
                  x:Name="_this">
            


            Видите разницу? Я тоже не вижу. Да, за семь прошедших лет никто пальцем не шевельнул, чтобы избавиться от избыточности кода.

            Давайте для сравнения взглянем на код странички ASP.NET 2006-го года (тоже из проекта тех лет):

                <%@ Page Language="C#" MasterPageFile="~/TrialBalance.Master" AutoEventWireup="true" EnableViewState="false" CodeBehind="Builds.aspx.cs" Inherits="PaulStovell.TrialBalance.MainWebsite.Builds" Title="Downloads - TrialBalance" %>
                <asp:Content ID="Content1" ContentPlaceHolderID="MainContentPlaceholder" runat="server">
                  <asp:PlaceHolder runat="server" Visible="false" ID="_downloadAreaPlaceholder">
                    <h1>Download</h1>
            


            Как эта разметка выглядит сегодня?
                @model BuildsViewModel	
                @section Main {
                  <h1>Download</h1>
                }
            


            Изначально я стал разработчиком WPF, потому что мне были не по душе ASP.NET Web Forms и модели вроде View State. Но сейчас, когда я оглядываюсь на проделанный ASP.NET путь, я вижу огромные изменения. От модели Web Forms до модели MVC, от синтаксиса ASPX до Razor — в лагере ASP.NET действительно занимались инновациями.

            Вот неполный список того, что сделано в ASP.NET и не сделано в WPF:

            Создан новый, дружественный человеку язык разметки (Razor). Когда пишешь на Razor, получаешь удовольствие. Написание XAML никогда не доставляло удовольствия. Более того, до того, как в ReSharper'е появился «Импорт пространства имён», оно было сущим кошмаром.

            Избраны дизайн-паттерны. И не говорите, что в WPF есть MVVM — да, WPF поддерживает байндинги, но в ядре WPF нет ни единой фичи, сколь-нибудь помогающей с MVVM. Это всё прилеплено сбоку через Blend Behaviors и сторонние фреймворки. В ASP.NET же весь стек построен на MVC.

            Попал в пропасть успеха. Вы реально можете написать поддерживаемое приложение на ASP.NET MVC, используя стандартный шаблон проекта. А стандартный шаблон WPF без сторонних фреймворков — это путь мучений и невзгод.

            Избрана расширяемость. Практически всё в ASP.NET MVC основано на интерфейсах и абстрактных классах, которые вы можете расширить, изменив тем самым поведение фреймворка. Готов поклясться, команда WPF слыхом не слыхивала про интерфейсы, а немногие абстрактные классы имеют internal конструкторы.

            Избран опен-сорс. ASP.NET включает jQuery и JSON.NET, и прекрасно совмещается с бесчисленными опен-сорсными инструментами. WPF, несмотря на нескончаемый список MVVM фреймворков, и несмотря на полную невозможность разработки поддерживаемого приложения без такового, до сих пор их не включает.

            Стал опен-сорсом. Исходники ASP.NET MVC были открыты с самого начала, но сейчас вообще весь стек ASP.NET стал опен-сорсным и принимает исправления извне. WPF — нет, и, откровенно говоря, вы бы и не захотели смотреть на код WPF: он ужасен (прим. перев.: можно оценить VirtualizingStackPanel).


            Статья написана в 2013. Что изменилось в 2015? Только одно — в заголовке статьи надо писать Девять лет WPF: что изменилось?
            • 0
              То есть разработка в ASP.Net с прикрученным сбоку jQuery — это хорошо,
              а разработка на WPF с прикрученным сбоку mvvm-фреймворком — это плохо?

              Ну вот когда появится не «бесконечный список», а MVVM-фреймворк, претендующий на промышленный стандарт — тогда можно думать о его включении. А пока как обычно, поставил решарпер (куда ж без него), прикрутил любимый фреймворк (куда ж без него)

              Возвращаясь к, с Razor можно разве что пару строчек xmlns: сэкономить, а всякие WindowState=«Maximized» всё равно писать придётся (ну или сразу можно удалить — будет как в примере «Как эта разметка выглядит сегодня?»). А всяких ASP.Net-овских ID в WPF писать никогда не заставляли.

              Только я вот ни разу не видел попыток от xmlns избавится. Похоже никого не беспокоит. А вот биндинги облегчаются легко и непринужденно (скажем, github.com/Alex141/CalcBinding) — это обязательно в комплект класть?
    • 0
      > И, мне кажется, что он умудряется работать быстрее, чем наше родное WPF приложение на Telerik.

      Мне кажется это не проблема WPF, а проблема Telerik.
      Попробуйте подгрузить 100500 данных в том же телерике в браузер — тормозить будет примерно так же, а памяти кушать больше.
      • –1
        Мнение перешедших на встроенный Chrome разработчиков Evernote:

        there were some problems we simply couldn’t fix: the blurry fonts, slow startup times, large memory footprint, and poor support for certain graphics cards were all issues that the technology behind 3.5 (Windows .net and WPF) was incapable of resolving
        • +1
          5 лет прошло, какой poor support for certain graphics cards?
  • +6
    Back in 2006, here's what the markup for a pretty basic Window looked like (taken from an app I worked on in 2006):
    <Window x:Class="PaulStovell.TrialBalance.UserInterface.MainWindow"
      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
      xmlns:tb="clr-namespace:PaulStovell.TrialBalance.UserInterface"
      xmlns:tbp="clr-namespace:PaulStovell.TrialBalance.UserInterface.Providers"
      xmlns:system="clr-namespace:System;assembly=mscorlib"
      Title="TrialBalance" 
      WindowState="Maximized"
      Width="1000"
      Height="700"
      Icon="{StaticResource Image_ApplicationIcon}"
      Background="{StaticResource Brush_DefaultWindowBackground}"
      x:Name="_this"
      >
    

    I mean, look at all that ceremony! x:Class! XML namespace imports! Why couldn't any of that stuff be declared in one place, or inferred by convention?

    Fortunately, it's now 2012, and things have come a long way. Here's what that code would look like if I did it today:

    <Window x:Class="PaulStovell.TrialBalance.UserInterface.MainWindow"
      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
      xmlns:tb="clr-namespace:PaulStovell.TrialBalance.UserInterface"
      xmlns:tbp="clr-namespace:PaulStovell.TrialBalance.UserInterface.Providers"
      xmlns:system="clr-namespace:System;assembly=mscorlib"
      Title="TrialBalance" 
      WindowState="Maximized"
      Width="1000"
      Height="700"
      Icon="{StaticResource Image_ApplicationIcon}"
      Background="{StaticResource Brush_DefaultWindowBackground}"
      x:Name="_this"
      >
    

    Spot the difference? Of course not, it was a trick question, nothing has changed since 2006 that would have made that less verbose.

    paulstovell.com/blog/six-years-of-wpf
    • +3
      Есть перевод на хабре
      habrahabr.ru/post/165273/
    • +2
      Вы статью наверное не читали. Это называется «зрелая технология». В мире WPF нет такой проблемы, как в вебе, что вы на 5 лет выпали из разработки — а вокруг куча непонятного, и вы даже не сможете найти работу! То ли дело WPF — вы спокойно можете взять отпуск на эти 5 лет, а после этого вернуться к проекту, и быть уверенным, что ваши знания ни капли не устарели. Уверенность в завтрашнем дне — наша цель.
      • +5
        Самое страшное здесь — то, что я даже не берусь утвеждать, пишете ли вы это в шутку, или серьезно.
        • +2
          Я думаю это было серьезно. По таким законам живет энтерпрайз мир.
          • +1
            Даже в энтерпрайз мире такой подход в лучшем случае означает потерю профессиональных навыков и самую тупую и скучную работу по поддержке старых систем. В теории конечно даже системы под DOS до сих пор кое-где живут и какими-то программистами поддерживаются…
            • 0
              Это выгодно компании. Всё остальное не важно.
              • 0
                Если это выгодно компании и не выгодно нам всегда можно уволится.
                • 0
                  Ну, в энтерпрайз ходят не ради интересной работы.
                  • 0
                    Вроде как в нашей отрасли еще никто не жаловался на безработицу и невозможность заработать на жизнь программированием в более интересных сферах.

                    В том числе кстати и в энтерпрайзе, но других его областях.
                    • 0
                      В энтерпрайз не только, и не столько за деньгами ходят. :)

                      За деньгами ходят в стартапы. В энтерпрайз ходят за стабильностью и спокойствием.
                    • 0
                      Это очень сильно зависит от места проживания.
  • 0
    Забыли ссылку на оригинал pragmateek.com/is-wpf-dead-the-present-and-future-of-wpf
    • 0
      Это не то, чтобы прямой перевод, а скорее вольное изложение с перепроверкой. Некоторые пункты в статье не соответствовали положению дел, какие-то лишь частично. Что-то дополнилось, что-то сократилось. Но в целом указать можно, как вдохновителя и отправную точку =)

      Если указать, что это перевод, то будет больше наездов, что не дословно, а пересказ какой-то и мол отсебятины много. Так что взвесив все за и против, от перевода отказались.
  • +4
    Могу лишь подтвердить фактом: уже 7 лет пишем различное ПО на WPF (в основном субподряд на интеграцию дизайна, но и под ключ решения тоже), и в последний год со стороны заказчиков крупного корпоративного сектора интерес большой к технологии, как никогда.
  • +2
    Фриланс. По ощущениям заказов с WPF стало ощутимо меньше. Зато еще больше стало заказов на web решения.
  • 0
    Все-таки спрошу, а что дальше? Не смотря на наличие позитивных сдвигов, которые вы описали выше, WPF так или иначе будет сходить на нет после, скажем, релиза Win10 и его расползания по девайсам (десктопы, планшеты, телефоны...). Куда копать, чтобы не остаться на обочине?
    • 0
      Web и Xamarin?
      • 0
        Я как-то привык считать, что web это одно, а десктоп — совсем другое… Хотя сейчас конечно даже для мобильников пишут на HTML/JS (PhoneGap/Cordova), но оно ведь не сильно эффективно получается, очень непросто все с производительностью. Xamarin же сейчас насколько я понимаю на пороге большого прорыва, из-за открытия исходников .Net, но пока это все не Production-ready же?
        • 0
          Есть еще новый www.telerik.com/nativescript он выглядит горааааздо интереснее Xamarin.Forms (который за год так и не стал менее унылым).
          У обычного Xamarin ниша есть и спрос растёт, но не будет большим. На нем имеет смысл писать только при двух условиях:
          — много общей логики на клиенте
          — у вас под рукой дешевый дотнетчик
          при этом оно не будет запускаться мгновенно и вы будете бороться с кучей утекающих грефов при сложном интерфейсе (android).
        • +3
          Для Microsoft-десктопа я вменямых перспектив не вижу. Microsoft просто полностью забросила это направление, что особенно хорошо заметно на фоне быстрого развития ASP.Net.

          Чуть выше уже приводили ссылку на хорошую статью Семь лет WPF: что изменилось?, правда прошло уже 8 лет, но кроме описываемых в ней проблем, есть еще очень серьезные проблемы с производительностью двухмерной графики — причем проблемы именно из-за кривой архитектуры рендеринга, которые как не сложно догадаться тоже никто не собирается решать — вот здесь исследование A Critical Deep Dive into the WPF Rendering System, из-за чего даже HTML5 в современных браузерах работает быстрее. Добавим к этому принципиальное нежелание Microsoft пускать WPF приложения в магазин…

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

          Xamarin же сейчас насколько я понимаю на пороге большого прорыва, из-за открытия исходников .Net, но пока это все не Production-ready же?


          Я имел в виду скорее миграцию в веб-разработку и мобильные платформы, в случае с Xamarin все-таки значительная часть знаний по .Net будет использована повторно.

          Когда я обдумывал перспективы для настольного хобби-проекта ничего лучше встраивание в приложение браузера и использования для интерфейса HTML не пришло в голову — в конце концов разработчик Evernote тоже пошли этим путем и перешли Chromium Embedded Framework из-за проблем с производительностью в WPF.

          there were some problems we simply couldn’t fix: the blurry fonts, slow startup times, large memory footprint, and poor support for certain graphics cards were all issues that the technology behind 3.5 (Windows .net and WPF) was incapable of resolving

          blog.evernote.com/blog/2010/10/26/evernote-4-for-windows-is-here/
          • 0
            Спасибо. Будем смотреть как оно попрет дальше…
          • +2
            Ятп принципиальное нежелание выпускать WPF в магазин как раз связано с их желанием максимально быстро похоронить это направление.
        • 0
          Xamarin, не смотря на периодические мелкие неприятности, чуть более, чем production-ready, и да, PhoneGap тоже.
  • –4
    А зачем он, если есть Qt?
    • +9
      Сделают Qt5 для .NET — сообщите. Желающих с C# переходить на C++ немного.
      • +5
        Сделали, кстати, немного осталось. QtSharp вполне :)
        • +3
          Где можно больше почитать, посмотреть и пощупать? В документации нашёл только мутную инструкцию по сборке. На сайте Mono QtSharp упомянут как «in early development». В гугле хоть шаром покати. Количество звёзд у репозитория тоже не внушает уверенности в готовости решения.
    • +2
      Писать такие вбросы в статье про WPF, где очевидно большая часть читателей комментариев — пользователи и любители WPF — это хабросамоубийство…

      Я тоже люблю Qt, но зачем об этом знать пользователям читающим про WPF?
      • +2
        Это не стан PHPшников, тут вбросы так близко к сердцу не принимают, если судить по соотношению плюсов и минусов. Всё-таки дотнетчики в себе и своём выборе больше уверены. :)

        Но раскрыть тему не помешало бы, да. Qt — вещь кроссплатформенная и с байндингами для многих языков, потому потенциально интересна дотнетчикам. К сожалению, с дотнетовыми байндингами для актуальной версии Qt, которая и представляет интерес, всё не так хорошо, как хотелось бы.
      • 0
        Вопрос скорее в C++.
  • +4
    Боюсь, что чтобы оживить wfp, недостаточно начать писать в блог спустя 5 лет. Кроме того, очевидно это уже другая команда.
    Так что пациент скорее мертв.
    На вопрос «что делать» ответ — web.
    • +2
      Странное решение: ведь WPF сделан не для web'а. На тему мертвости: его же используют, хотя могли бы и развлекаться с WinForms, студия прекрасно их поддерживает.
      • +1
        Используют массу мертвых технологий вроде PHP4, Delphi 6, WinForms или вообще COBOL и программ под DOS. В промышленной среде старые системы вообще живут очень долго.

        Вопрос в другом — есть ли смысл изучать и осваивать WPF сейчас если он до сих пор не используется? Оправдано ли такое вложение времени и средств с точки зрения дальнейших перспектив технологии?

        Web здесь рассматривается скорее с точки зрения применимости в реальных задачах — которые в случае с LOB очень часто представляют с собой много-много форм и табличек с записью и чтением из базы, для чего современного Web вполне хватит и каких-то особых преимуществ WPF не дает.
  • 0
    Про Делфи тоже так говорили…
  • 0
    в понедельник, 23 марта, команда WPF будет «вживую» отвечать на вопросы, в том числе о будущем WPF
    blogs.msdn.com/b/visualstudio/archive/2015/03/20/connect-live-wpf-team-live-q-and-a.aspx
  • 0
    Я вот сейчас пишу головоломку на WPF (вернее, его урезанной версии под Windows Store). Довольно легко и приятно пишется.
    Есть проблемы с производительностью при большом количестве элементов на экране. Но это не очень удивительно, так как везде используется векторная графику XAML.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка