有人在Silverlight 发布 http://forums.silverlight.net/forums/t/159237.aspxMVVM 目前缺乏标准化,因此每个人都有自己的风格。
这就是为什么我和 WPF Disciples 的一些人正在积极讨论每个人都同意的 MVVM 元素。我完全理解我们以不同的方式实现了该模式,我们混合了几种模式,或者根据我们项目的需要创建我们自己的模式,或者让开发人员的生活更轻松。但是忘记这些困难或项目的特殊需要。让我们讨论一下大家都同意的 MVVM 模式的标准规则。我已经发布我的一些想法在这里 http://michaelsync.net/2010/02/03/rules-of-mvvm以及。
为什么选择MVVM?
- Testabiltiy(ViewModel 比代码隐藏或事件驱动代码更容易进行单元测试)
- 用户体验设计师和开发人员之间的明确分离
- 增加视图的“可混合性”
- 永远不需要更改模型来支持视图的更改
- ViewModel 很少需要更改来支持视图的更改
- 没有重复的代码来更新视图
视野中该做和不该做的事情
- 不应包含任何要测试的逻辑:正如 Glenn 所说,MVVM 不是代码计数练习,我们可以在代码隐藏中编写代码。但你永远不应该编写任何你想测试的逻辑。例如:如果用户选择一个国家/地区,那么您希望在视图中显示州或城市的列表。这是业务需求,因此您应该进行单元测试来测试此逻辑。所以,你不应该把它写在代码隐藏中。
- 可以是控件或数据模板
- 保持视图尽可能简单。 :我们仍然可以在 XAML 中谨慎使用 Data Trigger 或 Value Converter 或 Visual State 或 Blend Behivor。
- 如果某些内容不可绑定,请使用附加属性:
ViewModel 中该做什么和不该做什么
- 视图和模型之间的连接器
- 保持视图状态,值转换(您可以创建要在 ViewModel 中显示的数据结构,而不是使用 ValueConverter。例如:您需要显示名称而不是名字和姓氏。您的模型可以有名字和姓氏名称,但您可以在 ViewModel 中创建名称属性。)
- 视图没有强或弱(通过接口)引用
- 使 VM 尽可能可测试(例如,不调用 Singleton 类)
- VM 中没有与控制相关的内容(因为如果您要更改视图,那么您也必须更改 VM。)
Model
- 可以是数据模型、DTO、POCO、自动生成的域类代理和 UI 模型,具体取决于您希望如何分离域服务和表示层
- 没有引用 ViewModel
您对此有何建议或意见?
我们小组中有一个分歧。有人说ViewModel中有View的接口就可以了。但也有人说,如果View Model有View的接口那就是MVP模式了。
我们的一位 MVVM 专家谈论 MVVM 与 MVP
视图 => 视图模型
- MVVM视图直接绑定到ViewModel并通过数据绑定与VM对话
- 在 MVP 中,视图绑定到挂在 SupervisingController 上的模型,或者根本不绑定(被动视图)。
视图模型 => 视图
MVVM
- INPC / 属性绑定
- Events
- 消息(事件聚合器/Messenger/RX 框架)
- 通过服务等中介
- 通过接口
- 通过委托(View 将委托传递给 VM,VM 可以使用该委托将其回调。例如,VM 可能会公开一个 SetActions 方法,View 会调用该方法传递委托。
MVP
在 MVP 情况下,标准是 Presenter 通过接口、数据绑定或通过属性(在被动视图的情况下)与视图进行对话。对于被动视图,属性不使用数据绑定,而是使用视图属性 getter 和 setter 直接设置控件值。
你觉得这个想法怎么样?
你认为ViewModel有View的接口可以吗?
如果您想添加更多,欢迎添加...:)
这篇文章的整体想法是为了在社区中获得对 MVVM 模式的相同理解。
我喜欢你写的。真正让我烦恼的事情之一是,很多人似乎将他们的虚拟机与他们的视图紧密耦合——如果你这样做,那么你可能还只是做旧的 XAML + 所有东西都被塞进了代码背后的东西。
我使用的模式是 MVVM 的一个轻微变体(但大部分是相同的)。就我个人而言,我喜欢将我的 ViewModel 作为接口提供给 View - 它使分离保持非常干净。这在做原型时有很多好处,视觉元素可以切换到视图中或从视图中切换出来,而对 ViewModel 影响很小或没有影响。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)