针对Silverlight的各种MVVM框架的优缺点是什么?

任何框架的缺点都是一样的:它是别人的代码,也是别人对模式的实现。你把解决方案的控制权让给了别人的代码。如果你对此很满意,那就去做吧。

但是MVVM是一个非常简单的模式实现它实际上非常简单;wpf和silverlight已经融入了大多数需要使绑定工作的核心组件,从而使mvvm工作。

我发现我真正需要做的是mvvm是一个跨类消息传递的事件聚合器,一个处理重复编写inotifypropertychanged的基本视图模型类,然后是一个连接依赖项的ioc容器。就这样。

在我使用组件应用程序ui块的经验之后,我倾向于回避其他任何人的“框架”。尤其是如果我能在短时间内自己写核心位。

在我目前的工作中,我们在我们的项目上做mvvm,我的基础设施实际上是两个类和接口,正如我上面所说的。

我不能代表列出的其他框架,但我可以说,我在mvvm light toolkit方面取得了巨大的成功。我赞同这样一种观点,即您可以在需要时“推出自己的”框架,但MVVM Light很小,不具感染力;它不接管您的应用程序体系结构,只是提供了MVVM的一些基本必需品:

1. RelayCommand-Command类,可以用于任何东西

2. 消息传递-执行消息传递和消息聚合的能力

3. ViewModelBase-实现INotifyPropertyChanged等。。。

4. ViewModelLocator-一个简单的实用程序,用于将ViewModels注入视图中。

我认为像组件应用程序UI块(以及它的Silverlight类似的Prism)这样的框架所引起的对框架的反应应该被一个轻量级和直接的框架所消除。