唉，SilverLight啊

搞了一段时间的WPF，深深的被那东西吸引了，用WPF开发个东西实在是忒happy了，尽管刚开始的时候忍不了WPF私吞Exception，忍不了傻不啦叽的FrameworkElement.Triggers就支持一个EventTrigger,而傻鸟的EventTrigger偏偏没有个Setter，所以想在某个特定的Event发生的时候对某个属性赋值还得去绕个大圈等等等等。

 据说，SilverLight号称WPF anyware，最近2.0release了，感觉可以花点时间研究一把，结果首先发现WPF中最强大的Binding到了SL里面，没了OneWayToSource，没了ElementName，最猥琐的是，在伊的Path语法当中明明支持hierarchical Binding，结果丫没有ICollectionView接口，做个在WPF中完全用xaml就能搞定的M-D还得借助代码。哦，DataProvider也没了……

 找到一篇抱怨文（原文：https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=333779&wa=wsignin1.0），贴在这了。

 ==============

I’m a big fan of Silverlight and coming from a .Net and WPF background, I was really looking forward to what Silverlight 2.0 had to offer. Sadly, I have ended up highly disappointed as I was hoping to port several high-profile financial industry applications to a more portable framework, but at the moment there are just too many obstacles :o(. It really seems the elegance and separation of concerns of WPF has been replaced by a framework that encourages ‘hard coding’, bad design and minimal reuse. It is somewhat reminiscent of old VB apps with business logic behind buttons! Don’t get me wrong, Silverlight as a Web technology does have enormous potential, but to tout it as being similar to ‘WPF’ is simply not true. I understand the need to streamline WPF, but Silverlight has done more than that, it has removed some of the fundamental principles that made WPF such a good technology. All of the demo applications published by Microsoft showing how easy it is to port between Silverlight /WPF are simply convenient ‘hello world’ type scenarios, and I believe all the marketing and hype around Silverlight and WPF similarities is sending out the wrong message. A WPF app done the WPF way cannot be easily ported to Silverlight, even down to the form definitions. The same is true of the reverse.

Below are some observations I made whilst in my first few hours of Silverlight whilst trying to accomplish several ‘basic’ tasks I would easily accomplish in WPF. I have separated the issues into two categories based on how they have affected my projects. I am hoping at least some of the issues below are resolved in Beta 2 or RTM, or failing that, make it into future Silverlight versions. Let’s keep our fingers crossed :o)

If any Microsoft guys could please give us a clue as to what to expect and when in the Silverlight roadmap then that would be great.



Absolute Show Stoppers
1. Where has MarkupExtension gone? How do we write our own? Are Silverlight bindings from markup “{Binding Forename, ...}” just ‘magic’?


2. How to handle databinding currency, especially with lists as there are no ICollectionView types? E.g. List<People> bound to a textbox, how do we know which person the textbox is displaying?

3. Binding is inconsistent between WPF and Silverlight

No ElementName source
No RelativeSource Self
BindingExpressions not compatible between Silverlight/WPF. Therefore form layout reuse is not possible.

4.No way to get Binding from a control. In WPF we were able to use techniques involving Bindings to know what control was bound to an object and vice versa.

5. No ErrorProvider. In WinForms and ASP.Net there is an out-of-the-box error provider. In WPF it is fairly easy to create an ErrorProvider by tracking the bindings and using AttachedProperties and style triggers with adorners. In Silverlight it seems an awkwardly difficult task! :o(

6. No Adorners. As mentioned above, ErrorProviders in WPF can be implemented with adorners and attached properties. Of course there are a multitude of other reasons as for why Adorners are useful.

7. No ControlTemplate Triggers, DataTemplate triggers, Style Triggers, DataTriggers.


Annoyances

1. No commands/input bindings/gestures – there goes the nicely layered architecture...

2. No ReadOnly DependencyProperties – not a major problem but it is a loss of encapsulation.

3. No tunnelled (preview) events.

4. No RoutedEvent class.

5. No UpdateSourceTrigger=PropertyChanged.

6. Visual / FrameworkContent element missing. Not a major problem, but certainly leads to interesting API changes.

7. No ability to specify a keyless style and have it applied to all matching TargetType..

8. Cannot specify FrameworkMetaData when creating dependency properties. So how to define inheritance behaviour, and default values etc?...

9. No style inheritance -> I.e it is not possible to do ‘BasedOn’...

10. No ValidationRule/ValidationResult.

11. No Xml DataBinding Support.

12. No DynamicResource.

13. No MultiTriggers. 

======================

Community Discussion

 

I agree with this "mismatch" problem, too. Silverlight also removes the Visual class and therefore the separation of concerns between the Logical Tree and Visual Tree. The Silverlight Team's explanation was that this "simplifies" the programming model, even though no defense is given as to why it needed to be simplified and absolutely no debate as to whether developers wanted it simplified. The problem statement above actually says it is "not a major problem", but I disagree.

It seems like Silverlight removes a lot of the infrastructure WPF's architects worked so hard to put in place. Moreover, those of us developing WPF applications are using that infrastructure.

All-in-all, these API differences just seem like a bad move going forward. Once Flex gets multi-platform OS support and Flex desktop applications become more common, there will be a lot less interest in Silverlight AND WPF.

 Posted by jzabroski on 7/16/2008 at 6:21 PM

Agreed. The view that Silverlight is just like WPF but on the web is incorrect, at least with Beta 2. I had expected to be able to use the same source code (IL code?) for controls and UI in WPF and in Silverlight, but I can see this isn't remotely possible.

Due to limitations/missing features in Silverlight I have to implement my functionality in a different way in Silverlight to WPF to "other RIA" technology. In a way my knowledge of WPF isn't helping me with Silverlight.

Bizzarely there are classes in the API that serve no purpose and are there "primarily because of WPF compatibility" (RoutedEvent documentation). This seems nonesense to me.

 Posted by rich257 on 7/17/2008 at 9:15 AM

Actually, the classes in Silverlight that are exist for compatibility with WPF are a good idea. It means Silverlight can eventually grow to become a subset of WPF. My concern is actually in the fact that the Object-Oriented Analysis used by the WPF Architects is being deconstructed by the Silverlight team. They're throwing away parts of the object analysis model by removing classes like Visual. This also complicates porting.

Still, it is clear from your comments that you agree that there is a mismatch and that it makes things confusing, and that knowledge used to build WPF apps has to be thrown away in order to build Silverlight apps.