Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Fortnum, Вы писали:
F>>Но выгода же очевидна — не надо писать каждый раз get {}; set {}; и загромождать логику ViewModel'и.
F>>Реализовать event'ы ValueChanging и ValueChanged также можно в этом MyValueViewModel.
F>>Чем это плохо?
V>Та ничем. Очевидно было сразу же, еще во времена WinForms, что обычные св-ва плохо подходят для непосредственного биндинга. Для биндинга лучше использовать абстракцию пина, с довольно сложным поведением. MS тоже до этого доперла, так появились DependecyProperty в WPF. Но для логической развязки, к сложному пину с одной стороны нужен такой же пин с другой стороны. Ты лишь разработал ответный пин.
Я так понимаю что DependencyProperty в первую очередт появились из желания пратачить к произвольному объекту свойства, определяемые контейнером, т.е. для лайоута. А раз уж сделали то можно и для байндинга приспособить дабы не плодить лишних абстракций.
V>И даже пофиг детали реализации. Что меня возмутило в WPF с первых же строчек знакомства — это абсолютно нессиметричная схема биндинга. К тому же, сама схема биндинга завязана тупо только на иерархию WPF. Даже компонентная модель как-то поуниверсальнее смотрелась.
Заточено в первую очередь под xaml, красивой архитектуру байндинга назвать врятли можно, зато не составляет сложностей в использовании в стандартных (= проработанных разработчиками впф) случаях.
V>А вообще, на тему св-в, реализованных в виде в виде легко соединимых м/у собой пинов, размышлял еще черти когда: http://www.rsdn.ru/forum/philosophy/1676773.1.aspx
Есть одно но — очень заморочено, вы вынуждаете под нужды рисовалки реализовывать специальные провайдеры данных, т.е выносите сложность на поверхность. В архитектуре впф берёшь обычный класс и байндишь к контролам — всё просто, понятно и вполне компактно. Код не засоряется лишними деталями байндинга. Сложность зашита глубоко в реализации байндинга и среднестатистический разработчик ничего о ней не знает и знать не должен. Что касается поддержки INotifyPropertyChanged, то меня удивляет почему до сих пор они не придумали языковой поддержки этой функциональности.
Здравствуйте, MxMsk, Вы писали:
MM>Видимо на такое не пошли из-за излишнего усложнения источника данных. Дернул Linq-ом объекты из базы и всё работает безо всяких пинов.
Ага, "само работает" .
В этом случае пины создаются в рантайм через рефлексию во время биндинга. И еще ищутся одноименные PropNameChanging/PropNameChanged через рефлексию, даже если их нет и нам оно не надо. Т.е. сам процесс биндинга очень дорогой получается. И там такая каша внутри, надо признать, что ручки бы по плечи отрубить бы.
Кстати, DependecyProperty тоже не обязательно было как экземпляры отдельных объектов (пинов то бишь) разрабатывать. Принципиально схема этого не требует, даже с учетом всех политик роутинга. Ведь можно было как в компонентной модели — все описать атрибутами, а в рантайме создавать экземпляры пинов по описаниям атрибутов. ИМХО, этот синтаксический кошмар в стиле С++ был сделан исключительно ради легковесности операции биндинга хотя бы с одной стороны (самой насыщенной подробностями). И то, в С++ синтаксически удобней бы вышло и-за встроенных в язык указателей на мемберы . Это я намекаю на необходимость упоминать требуемые мемберы при описании DependencyProperty через строковые литералы, что затрудняет рефакторинг.
И хотя мне не нравится как это сделано, но это ход в правильном направлении. Проблема там образовалось лишь от того, что забыли отделить мух от котлет. Продолжаем.
ИМХО, вот этот вариант с автоматическим созданием ответных пинов-источников сигнала через рефлексию по всяким name convention я бы оставил как fall-back вариант биндинга для бедных. А для общего случая предоставил бы удобные и внятные хелперы, чтобы свои объекты сразу можно было наделять специальными пинами-источниками сигналов. И все это универсально бы сделать в рамках донета, а не WPF-only. Тогда биндинг мог бы быть по-настоящему легковесным. И в своем прикладном коде это все запросто могло бы быть использовано, то бишь возможно было простое подключение get одного св-ва к set другого. В общем, по ссылке в предыдущем сообщении об этом чуть подробнее с примерами.
А то сейчас такая полезная возможность соединения св-в объектов доступна только для WPF и WCF компонентов, да еще и дизайн попахивает инженерным идиотизмом. Поясню. Мало того, что обе модели не совместимы и ни одна из них и близко не претендует на универсальность, так они еще умудрились намешать в кучу несколько совершенно ортогональные вещей: это собственно биндинг + поддержка его декларативности для работы через XAML + собственно dependency парадигма, реализованная (о нет!!!) в базовом классе.
В общем, слабовато у них с инженерией, двойка за дизайн... хоть AVK был когда-то со мной крайне не согласен с этой оценкой при рассмотрении WPF сразу по его выходу...
V>>К тому же, сама схема биндинга завязана тупо только на иерархию WPF. MM>Это что значит?
Что в WCF, например, свой DependecnyObject, а если хочу разработать просто компонент, который работал бы и там и там, то тут уже придется слегка изворачиваться.
Здравствуйте, Aviator, Вы писали:
A>Я так понимаю что DependencyProperty в первую очередт появились из желания пратачить к произвольному объекту свойства, определяемые контейнером, т.е. для лайоута. А раз уж сделали то можно и для байндинга приспособить дабы не плодить лишних абстракций.
Похожая модель работала в componentModel без dependency property, реализованная "расширителями". Куда как более правильный дизайн, ибо подразумевает комбинаторный подход к расширению набора св-в и даже ресолвит конфликты этих одноименных расширяемых св-в.
Там мотив был несколько другой.
A>Заточено в первую очередь под xaml, красивой архитектуру байндинга назвать врятли можно, зато не составляет сложностей в использовании в стандартных (= проработанных разработчиками впф) случаях.
V>>А вообще, на тему св-в, реализованных в виде в виде легко соединимых м/у собой пинов, размышлял еще черти когда: http://www.rsdn.ru/forum/philosophy/1676773.1.aspx
A>Есть одно но — очень заморочено, вы вынуждаете под нужды рисовалки реализовывать специальные провайдеры данных, т.е выносите сложность на поверхность. В архитектуре впф берёшь обычный класс и байндишь к контролам — всё просто, понятно и вполне компактно. Код не засоряется лишними деталями байндинга. Сложность зашита глубоко в реализации байндинга и среднестатистический разработчик ничего о ней не знает и знать не должен. Что касается поддержки INotifyPropertyChanged, то меня удивляет почему до сих пор они не придумали языковой поддержки этой функциональности.
Здравствуйте, vdimas, Вы писали:
V>Что в WCF, например, свой DependecnyObject, а если хочу разработать просто компонент, который работал бы и там и там, то тут уже придется слегка изворачиваться.
Вы с WWF не путаете случайно?
Здравствуйте, Codechanger, Вы писали:
V>>Что в WCF, например, свой DependecnyObject, а если хочу разработать просто компонент, который работал бы и там и там, то тут уже придется слегка изворачиваться. C>Вы с WWF не путаете случайно?
Здравствуйте, vdimas, Вы писали:
V>Ага, "само работает" . V>В этом случае пины создаются в рантайм через рефлексию во время биндинга. И еще ищутся одноименные PropNameChanging/PropNameChanged через рефлексию, даже если их нет и нам оно не надо. Т.е. сам процесс биндинга очень дорогой получается. И там такая каша внутри, надо признать, что ручки бы по плечи отрубить бы.
Как оно внутри — неважно. "Само работает" — это значит, что работает без нашего активного участия
V>Кстати, DependecyProperty тоже не обязательно было как экземпляры отдельных объектов (пинов то бишь) разрабатывать. Принципиально схема этого не требует, даже с учетом всех политик роутинга. Ведь можно было как в компонентной модели — все описать атрибутами, а в рантайме создавать экземпляры пинов по описаниям атрибутов. ИМХО, этот синтаксический кошмар в стиле С++ был сделан исключительно ради легковесности операции биндинга хотя бы с одной стороны (самой насыщенной подробностями). И то, в С++ синтаксически удобней бы вышло и-за встроенных в язык указателей на мемберы . Это я намекаю на необходимость упоминать требуемые мемберы при описании DependencyProperty через строковые литералы, что затрудняет рефакторинг.
Как ты собираешься описывать атрибутами обработчики изменения, валидации и корректировки значений свойств? DependencyProperty — это не только Binding.
Да, строковые литералы раздражают.
V>И хотя мне не нравится как это сделано, но это ход в правильном направлении. Проблема там образовалось лишь от того, что забыли отделить мух от котлет. Продолжаем. V>ИМХО, вот этот вариант с автоматическим созданием ответных пинов-источников сигнала через рефлексию по всяким name convention я бы оставил как fall-back вариант биндинга для бедных. А для общего случая предоставил бы удобные и внятные хелперы, чтобы свои объекты сразу можно было наделять специальными пинами-источниками сигналов. И все это универсально бы сделать в рамках донета, а не WPF-only. Тогда биндинг мог бы быть по-настоящему легковесным. И в своем прикладном коде это все запросто могло бы быть использовано, то бишь возможно было простое подключение get одного св-ва к set другого. В общем, по ссылке в предыдущем сообщении об этом чуть подробнее с примерами.
V>А то сейчас такая полезная возможность соединения св-в объектов доступна только для WPF и WCF компонентов, да еще и дизайн попахивает инженерным идиотизмом. Поясню. Мало того, что обе модели не совместимы и ни одна из них и близко не претендует на универсальность, так они еще умудрились намешать в кучу несколько совершенно ортогональные вещей: это собственно биндинг + поддержка его декларативности для работы через XAML + собственно dependency парадигма, реализованная (о нет!!!) в базовом классе. V>В общем, слабовато у них с инженерией, двойка за дизайн... хоть AVK был когда-то со мной крайне не согласен с этой оценкой при рассмотрении WPF сразу по его выходу...
Разница в сущности в том, что ты предлагаешь сделать Binding глобальной фичей .Net, а MS его сделала фичей только WPF.
V>>>К тому же, сама схема биндинга завязана тупо только на иерархию WPF. MM>>Это что значит? V>Что в WCF, например, свой DependecnyObject, а если хочу разработать просто компонент, который работал бы и там и там, то тут уже придется слегка изворачиваться.
Так и Binding — механизм WPF.
Много букв очень . Для меня, как практика, вполне приемлем текущий дизайн. Да, несколько муторно реализовывать свойства, но с другой стороны не так уж и много времени и главное — по силам даже начинающему разработчику, что немаловажно для UI фреймворка. Да, было бы приятно если бы на уровне языка была поддержка INotifiyPropertyChanged, но именно приятно, необходимости не вижу. Если избавиться от строковых констант, как я описал выше, то проблема с рефакторингом стоит не так остро, так что жить вполне можно.
Здравствуйте, MxMsk, Вы писали:
V>>Ага, "само работает" . V>>В этом случае пины создаются в рантайм через рефлексию во время биндинга. И еще ищутся одноименные PropNameChanging/PropNameChanged через рефлексию, даже если их нет и нам оно не надо. Т.е. сам процесс биндинга очень дорогой получается. И там такая каша внутри, надо признать, что ручки бы по плечи отрубить бы.
MM>Как оно внутри — неважно. "Само работает" — это значит, что работает без нашего активного участия
Я же говорю, вариант "биндинга для бедных" никто не отменял. Очень хорошо такой вариант работает в статическом биндинге. Но совершенно неприемлим, если мы используем, например, паттерн State, и довольно часто прыгаем по состояниям. Тут уже придется весь биндинг ручками, в случае отсутствия некоего единого callback-интерфейса для всех состояний (что порой удобно)... а могли бы использовать готовый универсальный механизм биндинга.
V>>Кстати, DependecyProperty тоже не обязательно было как экземпляры отдельных объектов (пинов то бишь) разрабатывать. Принципиально схема этого не требует, даже с учетом всех политик роутинга. Ведь можно было как в компонентной модели — все описать атрибутами, а в рантайме создавать экземпляры пинов по описаниям атрибутов. ИМХО, этот синтаксический кошмар в стиле С++ был сделан исключительно ради легковесности операции биндинга хотя бы с одной стороны (самой насыщенной подробностями). И то, в С++ синтаксически удобней бы вышло и-за встроенных в язык указателей на мемберы . Это я намекаю на необходимость упоминать требуемые мемберы при описании DependencyProperty через строковые литералы, что затрудняет рефакторинг. MM>Как ты собираешься описывать атрибутами обработчики изменения, валидации и корректировки значений свойств?
MS с самого начала использует некий name convention относительно событий валидирования св-в. Добавить в этот convention всё что надо.
Опять же, я не агитирую за этот путь, лишь демонстрирую разворот в сторону явного описания биндинга в С++ стиле. И утверждаю, что пойдя по этому пути, очень отличному от аттрибутов, необходимо было доработать декомпозицию. Т.е., если мы спустились с атрибутов до объектов, то необходимо было придерживаться популярных принципов ООП.
В случае атрибутов у нас неплохая декомпозиция идет изначально, как оно обычно бывает при слабой связанности и декларативном описании, и которое в свою очередь — суть композиция ранее определенных фич.
MM>DependencyProperty — это не только Binding.
Золотые слова! Только увидеть это надо было ДО разработки, а не после.
MM>Разница в сущности в том, что ты предлагаешь сделать Binding глобальной фичей .Net, а MS его сделала фичей только WPF.
И еще фичей WWF, и до этого в ComponentModel, которую WinForms юзает, и которая наполовину (со стороны источника данных) задействована и сейчас в WPF/WWF.
V>>Что в WCF, например, свой DependecnyObject, а если хочу разработать просто компонент, который работал бы и там и там, то тут уже придется слегка изворачиваться. MM>Так и Binding — механизм WPF.
Во-первых нет, а во-вторых, конкретно в биндинге WPF нет ничего, специфичного для GUI. Вообще ничего.
Здравствуйте, vdimas, Вы писали:
V>Я же говорю, вариант "биндинга для бедных" никто не отменял. Очень хорошо такой вариант работает в статическом биндинге. Но совершенно неприемлим, если мы используем, например, паттерн State, и довольно часто прыгаем по состояниям. Тут уже придется весь биндинг ручками, в случае отсутствия некоего единого callback-интерфейса для всех состояний (что порой удобно)... а могли бы использовать готовый универсальный механизм биндинга.
Круто, но я не понял. Чего не хватает?
V>>>Кстати, DependecyProperty тоже не обязательно было как экземпляры отдельных объектов (пинов то бишь) разрабатывать. Принципиально схема этого не требует, даже с учетом всех политик роутинга. Ведь можно было как в компонентной модели — все описать атрибутами, а в рантайме создавать экземпляры пинов по описаниям атрибутов. ИМХО, этот синтаксический кошмар в стиле С++ был сделан исключительно ради легковесности операции биндинга хотя бы с одной стороны (самой насыщенной подробностями). И то, в С++ синтаксически удобней бы вышло и-за встроенных в язык указателей на мемберы . Это я намекаю на необходимость упоминать требуемые мемберы при описании DependencyProperty через строковые литералы, что затрудняет рефакторинг. MM>>Как ты собираешься описывать атрибутами обработчики изменения, валидации и корректировки значений свойств?
V>MS с самого начала использует некий name convention относительно событий валидирования св-в. Добавить в этот convention всё что надо.
Этот механизм абсолютно не обязателен к использованию. У нас в проекте вообще такого нет. И потом, тот же рефакторинг превратиться в сущий ад... А уж как вызывать валидацию или корректировку из кода, совсем непонятно.
V>Опять же, я не агитирую за этот путь, лишь демонстрирую разворот в сторону явного описания биндинга в С++ стиле. И утверждаю, что пойдя по этому пути, очень отличному от аттрибутов, необходимо было доработать декомпозицию. Т.е., если мы спустились с атрибутов до объектов, то необходимо было придерживаться популярных принципов ООП. V>В случае атрибутов у нас неплохая декомпозиция идет изначально, как оно обычно бывает при слабой связанности и декларативном описании, и которое в свою очередь — суть композиция ранее определенных фич.
MM>>DependencyProperty — это не только Binding. V>Золотые слова! Только увидеть это надо было ДО разработки, а не после. MM>>Разница в сущности в том, что ты предлагаешь сделать Binding глобальной фичей .Net, а MS его сделала фичей только WPF. V>И еще фичей WWF, и до этого в ComponentModel, которую WinForms юзает, и которая наполовину (со стороны источника данных) задействована и сейчас в WPF/WWF.
Ну, тут только гадать. Вообще, привязка данных не такая уж простая вещь. Взять хотя-бы тот же Dispatcher. Как его вписать в ComponentModel? А ведь он нужен, чтобы нормально разруливать многопоточность. В-общем, я не настолько углубленно знаю исходники .Net, чтобы уверено утверждать, якобы MS ничего не стоило сделать Binding повсеместным.
V>>>Что в WCF, например, свой DependecnyObject, а если хочу разработать просто компонент, который работал бы и там и там, то тут уже придется слегка изворачиваться. MM>>Так и Binding — механизм WPF. V>Во-первых нет, а во-вторых, конкретно в биндинге WPF нет ничего, специфичного для GUI. Вообще ничего.
Я не о концепции привязки данных вообще, а о реализации, в которой Binding — это не средство BCL, а средство WPF.
MM>Это резко повысило бы уровень агитации за язык. Только нужно еще кое-что — количество программистов. Сейчас желающих работать на Nemerle и F# найти наверняка очень сложно и дорого. Проекту еще жить.
Поспорю фактом. На мои первые отзывы о Nemerle в реальном проекте в асю несколько человек ломанулось с вопросом есть ли вакансии, и просьбой стучать сразу как будут. Так что думаю пока язык интересен и нов — желающих писать на нём найти сравнительно легко, и квалификация этих желающих таки выше чем обычных прогеров.
Здравствуйте, MxMsk, Вы писали:
MM>Ну, тут только гадать. Вообще, привязка данных не такая уж простая вещь.
Разве? Мне казалось, тут давно все понятно было еще со времен COM и MFC. И практически ничего нового именно в плане привязки данных мы не увидели. Мы увидели подвижки по декларативности и по построенной на этой декларативности параметризуемости отображения юзверских и не только типов данных. Но! Мухи отдельно, котлеты — отдельно. Декларативностью занимается совершенно отдельный механизм, который использует имеющиеся механизмы биндинга для реализации своих фич. Т.е. сам биндинг "понятия не имеет" как, кто и для чего его использует.
MM>Взять хотя-бы тот же Dispatcher. Как его вписать в ComponentModel?
Никак. Это тоже отдельная вещь совершенно. Задача биндинга состоит в распространении сигнала от источника к подписчикам. Для этого надо:
— подписаться на изменения данных источника
— сообщать об изменении подписчикам.
Диспатчер мог бы быть как прокси от источника к подписчикам, и тут сценариев могло бы быть довольно много. Доставка событий — это вообще задача интересная сама по себе. Чего только диспатчеры COM/OLE стоят, работающие абсолютно прозрачно для скриптов и программ на VB в свое время . Но в дотнете все как-то напрямую и топорно. Диспатчер сделан в виде подменяемого "плагина" и даны несколько его реализаций по некоему жесткому АПИ. И это уже при наличии более одной работающей системы маршаллинга вызовов в дотнете. В общем, тот самый "фатальный недостаток", проявляющийся среди разрозненных команд разработчиков внутри одной конторы.
MM>А ведь он нужен, чтобы нормально разруливать многопоточность. В-общем, я не настолько углубленно знаю исходники .Net, чтобы уверено утверждать, якобы MS ничего не стоило сделать Binding повсеместным.
Поверь, они на биндинге и диспатчинге собаку съели. Другой такой же развитой инфраструктуры как COM/DCOM/OLE/ActiveX/COM+, вообще никто никогда не делал. По количеству реализованных сценариев и обыгранных мелочей, и по общей эффективности никакая CORBA и рядом не валялась (ближайший конкурент, отстававший лет на 15-20). Просто выглядит так, будто сейчас биндинг/диспатчинг писали совсем другие люди, без всего этого предварительного опыта. ИМХО, даже в исходники не потрудились заглянуть, хотя они им доступны.
Здравствуйте, Aviator, Вы писали:
A>Ну и разрыв мозга, почти ничего не понял .
Спрашивай, не стесняйся. Если дейтсивтельно интересно, можно любые упоминания уточнить до конкретных типов из дотнетных либ. Просто предполагалось, что собеседники и так в курсе.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Aviator, Вы писали:
A>>Ну и разрыв мозга, почти ничего не понял .
V>Спрашивай, не стесняйся. Если дейтсивтельно интересно, можно любые упоминания уточнить до конкретных типов из дотнетных либ. Просто предполагалось, что собеседники и так в курсе.
А практический смысл? Какой бы плохой или хорошой не был wpf, это всё равно mainstream для ui в windows. И что касается байндинга имхо нааамного продвинутее винформсов.
Здравствуйте, Aviator, Вы писали:
V>>Спрашивай, не стесняйся. Если дейтсивтельно интересно, можно любые упоминания уточнить до конкретных типов из дотнетных либ. Просто предполагалось, что собеседники и так в курсе. A>А практический смысл? Какой бы плохой или хорошой не был wpf, это всё равно mainstream для ui в windows. И что касается байндинга имхо нааамного продвинутее винформсов.
С каких это пор оно mainstream? У меня только одно установленное приложение использует WPF, да и то, это приложение уж очень узконишевое.
ИМХО, WPF уйдет в небытие, уступив нишу сервелату. А последний гораздо более "вещь в себе". Да и по мультимедиа возможностям почему-то обгоняет WPF. Хотя сервелат смотрелся как эксперимент в первых версиях, но сегодня всё выглядит так, будто 2 продукта меняются местами. Теперь WPF идет как полигон для обкатки решений и идей для сервелата.
Здравствуйте, vdimas, Вы писали:
V>ИМХО, WPF уйдет в небытие, уступив нишу сервелату. А последний гораздо более "вещь в себе". Да и по мультимедиа возможностям почему-то обгоняет WPF. Хотя сервелат смотрелся как эксперимент в первых версиях, но сегодня всё выглядит так, будто 2 продукта меняются местами. Теперь WPF идет как полигон для обкатки решений и идей для сервелата.
Здравствуйте, vdimas, Вы писали:
V>С каких это пор оно mainstream? У меня только одно установленное приложение использует WPF, да и то, это приложение уж очень узконишевое.
Вопрос времени, слишком много написано на формсах.
V>ИМХО, WPF уйдет в небытие, уступив нишу сервелату. А последний гораздо более "вещь в себе". Да и по мультимедиа возможностям почему-то обгоняет WPF. Хотя сервелат смотрелся как эксперимент в первых версиях, но сегодня всё выглядит так, будто 2 продукта меняются местами. Теперь WPF идет как полигон для обкатки решений и идей для сервелата.
А разве это не один и тот же продукт для разных environment?
Здравствуйте, Aviator, Вы писали:
V>>С каких это пор оно mainstream? У меня только одно установленное приложение использует WPF, да и то, это приложение уж очень узконишевое. A>Вопрос времени, слишком много написано на формсах.
На формсах приложения легковеснее гораздо, запускаются в 2-5 раз быстрее. И потому на них продолжают писать аж бегом.
A>А разве это не один и тот же продукт для разных environment?
На первый взгляд близнецы-братья, но лишь на первый. Удивительно не то, что сервелат не имеет всех возможностей "полновесного" WPF, а то, что последний тоже не имеет многих интересных и важных фич сервелата. Я бы сказал — ключевых фич, требуемых для мультимедиа-приложений. Именно наличие этих ключевых фич в сервелате и наталкивает на мысли, что приоритет у него повыше будет. Предполагаю, что как только в сервелате будут реализованы все фичи WPF, последний умрет за ненадобностью.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Aviator, Вы писали:
V>>>С каких это пор оно mainstream? У меня только одно установленное приложение использует WPF, да и то, это приложение уж очень узконишевое. A>>Вопрос времени, слишком много написано на формсах.
V>На формсах приложения легковеснее гораздо, запускаются в 2-5 раз быстрее. И потому на них продолжают писать аж бегом.
Вопрос времени. Было дело, когда спорили зачем писать на с++, когда есть си.
A>>А разве это не один и тот же продукт для разных environment?
V>На первый взгляд близнецы-братья, но лишь на первый. Удивительно не то, что сервелат не имеет всех возможностей "полновесного" WPF, а то, что последний тоже не имеет многих интересных и важных фич сервелата. Я бы сказал — ключевых фич, требуемых для мультимедиа-приложений. Именно наличие этих ключевых фич в сервелате и наталкивает на мысли, что приоритет у него повыше будет. Предполагаю, что как только в сервелате будут реализованы все фичи WPF, последний умрет за ненадобностью.
Во первых, в студию эти ключевые фичи. А во вторых, если подумать, то если в области десктопа ms твёрдо на ногах, в вебе на данный момент его позиции вызывают сомнения. Так что ожидаемо, что первым делом ms пиарит нововведение в вебе.
