我对整个MVVM模式感到陌生,并且试图将我的头围绕在它周围。我目前试图弄清楚的是:在一个结构良好的解决方案中,ViewModel在哪里生存?WPF/MVVM - ViewModel在哪里?
目前我的设计看起来是这样的(排序):
- 应用程序(图)
- DomainSpecificCode(ClassLibrary)
- 网关(ClassLibrary)
如果我是添加到另一种类型的视图(例如ASP.NET或Silverlight),哪里会是ViewModel存在的最佳位置?
我对整个MVVM模式感到陌生,并且试图将我的头围绕在它周围。我目前试图弄清楚的是:在一个结构良好的解决方案中,ViewModel在哪里生存?WPF/MVVM - ViewModel在哪里?
目前我的设计看起来是这样的(排序):
如果我是添加到另一种类型的视图(例如ASP.NET或Silverlight),哪里会是ViewModel存在的最佳位置?
ViewModels应该进入应用层,因为它们往往是技术特定的。
例如,您可能希望根据ViewModel的状态将View属性绑定到特定的颜色。但是,Color是通过Windows窗体,ASP.NET和WPF上的不同类型实现的,因此无法在不同技术中重复使用ViewModel。
如果添加新应用程序,则还必须提供新的ViewModels。
最近,我建了一个MVVM桌面应用程序,它有2种口味:
两个exe文件都使用相同的视图模型
我能我的解决方案分为以下项目(库/ EXE):
仅通过使用“查看模型”就可以轻松构建控制台应用程序版本。控制台应用程序代码只有不到200行代码,并且基本上加载了ProjectViewModel并对其执行操作。
所以你说的视图模型的代码应该生活在同一个域中的特定代码项目作为视图代码?在WPF和Silverlight的情况下呢?如果代码是以Silverlight可以使用的方式编写的(我并不是说它是:(),我还应该为Silverlight应用程序和WPF应用程序编写单独的ViewModels吗?(对不起,如果这些看起来很愚蠢问题) – AshtonKJ 2009-12-22 11:53:09
它可能与View代码在同一个项目中,或者它可能存在于另一个项目中,重要的一点是ViewModel倾向于针对特定的技术,您可以为WPF和SL编写通用的ViewModels因为他们是如此相似,虽然 – 2009-12-22 11:59:36
太好了,谢谢你的回答,这听起来像我应该做一些测试,看看我是否可以在SL和WPF之间实现ViewModel的可重用性,然后我将有一个独立的ViewModel项目专门针对我去ASP.NET的情况。 – AshtonKJ 2009-12-22 12:13:54