Комментарии 24
Крутая вещь, но ее будущее довольно непонятное: WPF стагнирует, чистый Silverlight obsolet'ится, а в Windows Phone, библиотека избыточна и громоздка, на мой взгляд.
Если только рефакторить существующие бизнес-решения
Если только рефакторить существующие бизнес-решения
WPF застрял, но не отстал. Просто его всё ещё никто не обошёл.
А громоздкость Prism… Нужно просто применять её, когда проект сложный настолько, что чёрт ногу сломит. В относительно простых проектах она, разумеется, бесполезна.
А громоздкость Prism… Нужно просто применять её, когда проект сложный настолько, что чёрт ногу сломит. В относительно простых проектах она, разумеется, бесполезна.
А как же Windows RT? К примеру, в Windows Store Business Apps Guidance using Prism for Windows Runtime Prism применяется для создания Windows RT приложения. Библиотека не очень громоздка, все части внутри неё слабо связаны. В простых приложениях можно использовать только классы NotificationObject и DelegateCommand. Да и то, если есть вероятность, что приложение нужно будет в дальнейшем развивать и поддерживать, то лучше сразу начать писать его правильно, чтобы не пришлось потом переписывать всё заново.
Ее будущее непонятно ровно в той же степени, что будущее настольных и планшетных приложений, ведь если начинать новый проект для десктопа, то не брать же WinForms, а WPF почти автоматически означает CAL.
Рискую заполучить минусов, но я не могу не высказаться.
Хоть убейте меня, я ну никак не могу понять, почему все считают, что нельзя брать в расчёт WinForms?
Да, я согласен, что в WPF полно плюшек, но…
Мы скоро начнём переписывать проект, написанный под WPF на WinForms.
Есть целый парк машин, которые пашут под Windows POS Ready 2009 и имеющие следующие характеристики: Celeron 1.8 Ghz, 512Mb DDR1, древняя встроенная видеокарта без аппаратного ускорения. Под такой платформой WPF работает медленно, ещё и глючит с отображением айтемов из ComBox, например. А вот аналог, написанный на Delphi, работает шикарно.
WinAPI, на котором зиждится WinForms, вылизан до мозга костей, а WPF — нет. Если постараться, то под WinForms можно сделать достаточно симпотичный интерфейс.
Вы вообще видели внутренний код WPF? Загляните в длиннющий StackTrace после какого-нибудь исключения. Вы увидите мириады вызовов методов, которые принимают с десяток аргументов. С десяток! Что это за говнокод? Кто все эти люди, которые такое понаписали?
Такое ощущение, что мимо Майкрософта проходил талантливый инженер, который предложил идею WPFa, Майкрософту она понравилась и её реализовали… реализовали бог знает кто, кто-то уровня человека, который реализовал SerialPort в .NET.
Вот когда видишь такую реализацию становится неприятно использовать это.
Наш новый тимлид сказал решительное нет WPFу.
Я не считаю WPF плохой технологией, но видит бог, реализовать можно было и получше.
Хоть убейте меня, я ну никак не могу понять, почему все считают, что нельзя брать в расчёт WinForms?
Да, я согласен, что в WPF полно плюшек, но…
Мы скоро начнём переписывать проект, написанный под WPF на WinForms.
Есть целый парк машин, которые пашут под Windows POS Ready 2009 и имеющие следующие характеристики: Celeron 1.8 Ghz, 512Mb DDR1, древняя встроенная видеокарта без аппаратного ускорения. Под такой платформой WPF работает медленно, ещё и глючит с отображением айтемов из ComBox, например. А вот аналог, написанный на Delphi, работает шикарно.
WinAPI, на котором зиждится WinForms, вылизан до мозга костей, а WPF — нет. Если постараться, то под WinForms можно сделать достаточно симпотичный интерфейс.
Вы вообще видели внутренний код WPF? Загляните в длиннющий StackTrace после какого-нибудь исключения. Вы увидите мириады вызовов методов, которые принимают с десяток аргументов. С десяток! Что это за говнокод? Кто все эти люди, которые такое понаписали?
Такое ощущение, что мимо Майкрософта проходил талантливый инженер, который предложил идею WPFa, Майкрософту она понравилась и её реализовали… реализовали бог знает кто, кто-то уровня человека, который реализовал SerialPort в .NET.
Вот когда видишь такую реализацию становится неприятно использовать это.
Наш новый тимлид сказал решительное нет WPFу.
Я не считаю WPF плохой технологией, но видит бог, реализовать можно было и получше.
Здесь проблема в железе. На любой современной машине, даже стоимостью 100$ ваше приложение пойдет на ура. Если у видеокарты нет вообще поддержки DirectX, то, конечно вся нагрузка ложится на этот несчастный Celeron.
Сказать «здесь проблема в железе» — ничего не сказать. В нашем случае, что сказали бы разрабы? — «Спасибо, кэп», но нам от этого не легче, а заказчик не собирается обновлять парк машин. А ещё вам только кажется, что железо за 100$ на ура тянет любые WPF-приложения уровня point of service. Это раз. Ну и про реализацию самого WPF что вы скажете?
Ну и последнее, чем плох WinForms для стандартных desktop-приложений? Столько все писали под MFC, под Delphi, под WinForms, потом бах — «фууу, WinForms — говно, как жеж можно использовать таких древних мамонтов?».
По факту, ИМХО, львиная доля потребностей заказчиков в случае стандартного десктопного приложения покрывается WinForms + ADO.NET. Стандартный набор.
Ну и последнее, чем плох WinForms для стандартных desktop-приложений? Столько все писали под MFC, под Delphi, под WinForms, потом бах — «фууу, WinForms — говно, как жеж можно использовать таких древних мамонтов?».
По факту, ИМХО, львиная доля потребностей заказчиков в случае стандартного десктопного приложения покрывается WinForms + ADO.NET. Стандартный набор.
Честно говоря, меня не очень беспокоит, как он устроен внутри до тех пор, пока он исправно работает, ведь я не сотрудник Microsoft, у меня свои задачи. К тому же, если рассматривать WinForms не просто как обертку, а вместе с нативной частью, то это был тоже далеко не шедевр.
То, что на старом железе подойдет WinForms не говорит о том, что WinForms подойдет везде. На самом деле я даже не уверен, что и в вашем случае это будет решением проблемы. Вы уже пробовали собрать прототип или только планируете?
То, что на старом железе подойдет WinForms не говорит о том, что WinForms подойдет везде. На самом деле я даже не уверен, что и в вашем случае это будет решением проблемы. Вы уже пробовали собрать прототип или только планируете?
Win Forms идеально подходит в том случае, если есть ТЗ, уверенность, что это ТЗ не будет меняться, и приложение простое в плане логики и пользовательского интерфейса. Если это не удовлетворяется, то начинают появляться самописные контролы на несколько тысяч строк, самописная инфраструктура, которая на 90% повторяет то, что уже есть в Prism, самописные сервисы, которые уже есть в, к примеру, Enterprise Library, и так далее, после чего поддержка превращается в кошмар. На WPF, кстати, тоже можно писать быстрые интерфейсы не требовательные к ресурсам, но, к сожалению, для этого нужно разбираться в том, как WPF работает, и знать техники оптимизации.
Насчёт внутренностей согласен, волосы иногда встают дыбом. Расширяемость тоже могла бы быть лучше, чтобы сделать что-то совсем уж нестандартное, приходится повозиться. Но, с другой стороны, после некоторого опыта работы с WPF, какой-либо другой подход к созданию UI кажется совершенно неестественным.
Насчёт внутренностей согласен, волосы иногда встают дыбом. Расширяемость тоже могла бы быть лучше, чтобы сделать что-то совсем уж нестандартное, приходится повозиться. Но, с другой стороны, после некоторого опыта работы с WPF, какой-либо другой подход к созданию UI кажется совершенно неестественным.
Ваш случай слишком специфичен. Когда заказчик ставит некие жёсткие рамки, то в любом случае придётся выкручиваться. Был бы парк машин ещё похуже — пришлось бы писать на гольном WinAPI — от этого уже WinForms резко станет плохой технологией?
Под WinForms надо ОЧЕНЬ постараться, чтобы сделать что-то этакое. Я ещё помню, как разработчики боготворили эту технологию именно из-за невероятной простоты настройки контролов. Поменять внешний вид кнопочки парой строчек — это казалось чем-то невероятным после WinAPI и MFC. Сейчас аналогично WPF предоставляет такие офигенные возможности, которые на WinForms маловероятно можно было бы реализовать даже с огромными затратами.
И зачем Вам лезть в StackTrace? Да, в современном мире продвинутые и крутые технологии требуют абстракций. И что? Будем кодить на Assembler?
Честно говоря, после WPF мне к WinForms страшно приближаться. В нём всё топорное, убогое, заточенное. Шаг влево, шаг вправо — и приходится писать сотни/тысячи строк кода, хотя на WPF это бы реализовывалось десятком строк.
Под WinForms надо ОЧЕНЬ постараться, чтобы сделать что-то этакое. Я ещё помню, как разработчики боготворили эту технологию именно из-за невероятной простоты настройки контролов. Поменять внешний вид кнопочки парой строчек — это казалось чем-то невероятным после WinAPI и MFC. Сейчас аналогично WPF предоставляет такие офигенные возможности, которые на WinForms маловероятно можно было бы реализовать даже с огромными затратами.
И зачем Вам лезть в StackTrace? Да, в современном мире продвинутые и крутые технологии требуют абстракций. И что? Будем кодить на Assembler?
Честно говоря, после WPF мне к WinForms страшно приближаться. В нём всё топорное, убогое, заточенное. Шаг влево, шаг вправо — и приходится писать сотни/тысячи строк кода, хотя на WPF это бы реализовывалось десятком строк.
Продвинутые, крутые технологии, требующие абстракций заставляют писать методы, принимающие 10 аргументов?
Во-первых, не припомню, чтобы меня при работе с WPF заставляли это делать. Не напомните?
Во-вторых, это стопроцентный показатель плохой и никуда не годной технологии?
Во-вторых, это стопроцентный показатель плохой и никуда не годной технологии?
Я могу напомнить как удобно работать с DependencyProperty. Их нагороженные объектные модели сделали сложное там, где можно было и попроще.
А ещё это объясняет почему WPF так требователен к ресурсам. Он мог бы быть куда менее требовательным. Но нет, ему надо внутри вызывать сотни методов с 10 аргументами, множество из которых надо откопировать.
А ещё это объясняет почему WPF так требователен к ресурсам. Он мог бы быть куда менее требовательным. Но нет, ему надо внутри вызывать сотни методов с 10 аргументами, множество из которых надо откопировать.
В принципе согласен. С начала Dependency Property казались жутью. Но есть же удобные «сниппеты», да и используемость DP сильно ограничена (в основном мы используем обычные автопроперти с NotifyPropertyChanged/Fody).
И опять же, Вы слишком преувеличиваете тормознутость WPF. Наши заказчики на неё не жаловались. И вроде все очень довольны. Особенно они в восторге от крутейшего интерфейса (всё-таки Telerik-овские контролы + допиливание производят огроменный ВАУ-эффект), а их хотелки весьма и весьма специфичны. На WinForms мы бы их реализовывать наверно бы и не взялись. Разве что на GDI+ (Graphics) вручную рисовать.
Да и я, честно говоря, не знаю, как можно было бы реализовать лучше. Издалека, конечно, кажется, что можно было сделать оптимальней… Но WPF страшно сложен. Мы даже не представляем насколько там всё внутри. Не зря mono отказались от его реализации, наверно.
И опять же, Вы слишком преувеличиваете тормознутость WPF. Наши заказчики на неё не жаловались. И вроде все очень довольны. Особенно они в восторге от крутейшего интерфейса (всё-таки Telerik-овские контролы + допиливание производят огроменный ВАУ-эффект), а их хотелки весьма и весьма специфичны. На WinForms мы бы их реализовывать наверно бы и не взялись. Разве что на GDI+ (Graphics) вручную рисовать.
Да и я, честно говоря, не знаю, как можно было бы реализовать лучше. Издалека, конечно, кажется, что можно было сделать оптимальней… Но WPF страшно сложен. Мы даже не представляем насколько там всё внутри. Не зря mono отказались от его реализации, наверно.
С DependencyProperty приходится работать напрямую в довольно малом количестве случаев. Вообще, они были необходимы для, как раз таки, увеличения производительности приложения. В отличии от WinForms, где на формочке присутствует, в среднем, дюжина элементов управления, в WPF, благодаря шаблонам и особенностям разметки, в визуальном дереве могут быть тысячи элементов одновременно. Каждый элемент в WPF имеет почти сотню различных свойств. Если бы не DependencyProperty, то одно приложение требовало бы под гигабайт оперативной памяти, как минимум.
Ну а методы с 10 аргументами в публичный интерфейс почти не вылезают, да и, в некоторых случаях, это может в некоторой мере повысить производительность. Быстрее передать 10 параметров в метод, особенно по ссылке, чем создавать для этого отдельный объект в куче.
Ну а методы с 10 аргументами в публичный интерфейс почти не вылезают, да и, в некоторых случаях, это может в некоторой мере повысить производительность. Быстрее передать 10 параметров в метод, особенно по ссылке, чем создавать для этого отдельный объект в куче.
Не понятно, зачем переводить MSDN. Если разработчик не может прочитать MSDN, то Prism ему вряд ли уже поможет.
Во-первых, для того, чтобы больше людей узнало о том, что есть такая штука, как Prism. Во-вторых, это, по большей части, книга, выложенная на MSDN, так что можно считать, что это перевод книги. :) В-третьих, для того, чтобы её прочитать на английском, нужно очень много терпения и знания этого самого английского, всё-таки материал не простой, и его довольно много.
Раньше у Microsoft была проблема: с помощью их фреймворков можно было делать только простые и стандартные приложения, любой шаг в сторону вызывал боль и страдания. Наконец-то они исправились! Теперь написание самых простых и стандартных приложений вызывает боль и страдания, любой шаг в сторону теперь возможен, только нужно дописать тонны кода, правда на действительно больших РЕАЛЬНЫХ проектах оно до сих пор не работает :)
Представляю вашему вниманию расширение для Visual Studio 2012, 2013 которое содержит шаблоны для построения расширяемого приложения используя Prism. Содержит шаблоны проектов: Prism Shell — для создания ядра расширяемой программы, Prism module — для создания независимых встраиваемых в оболочку Shell модулей. Есть шаблоны для F# и для C# (Prism Shell FSharp, Prism module FSharp, Prism Shell CSharp, Prism module CSharp) Ссылка для скачивания VSIX устанавливающегося расширения
Делал на Net 4.5.1. Шаблоны проектов для F# сделаны на ядре F# 3.1.2.
Делал на Net 4.5.1. Шаблоны проектов для F# сделаны на ядре F# 3.1.2.
Большое спасибо за перевод
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Руководство разработчика Prism — часть 1, введение