罗伯特马丁说:"一个班级改变的理由永远不应该超过一个".
让我们考虑绑定到View的ViewModel类.ViewModel可能(甚至可能)由彼此不相关的属性组成.对于小视图,ViewModel可能非常一致,但是当应用程序变得更加复杂时,ViewModel将公开可能因不同和无关原因而发生变化的数据.
我们是否应该在ViewModel类的情况下担心SRP原则？
阅读完所有关于Model-View-ViewModel架构的StackOverflow条目以及网上大部分现有资源后,我得出的结论是它是构建SOLID Silverlight应用程序的事实上的标准.
我开始使用这种架构来规划我的下一个应用程序.该应用程序的要求之一是构建或更改可视组件结构.例如,响应用户交互,我想以编程方式将未知的编译时数量的矩形和椭圆附加到特定的Canvas或Canvases.
我开始扭曲我的想法来应用MVVM模式,并考虑负责连接新组件的代码应该去哪里.我得出结论,它不属于任何MVVM层,因此不可能在需要在运行时操作组件树的情况下应用这种架构.
有没有办法在这些风格中使用Model-View-ViewModel,或者仅限于使用固定的View组件结构？
.NET RIA服务被描述为Silverlight的n层框架.我一直在想这个框架和Model-View-ViewModel模式之间的关系是什么.他们是冲突还是你看到了协同组合的潜力？