MVVM标准化
MVVM中的某些人目前缺乏标准化，因此每个人都有自己的风格 这就是为什么我和WPF弟子中的几个人正在积极讨论大家都同意的MVVM的哪些元素。我完全理解我们以不同的方式实现了该模式，我们混合了几种模式，或者根据项目的需要创建了我们自己的模式，或者使开发人员的生活更轻松。。但是，忘记那些困难或项目的特殊需要。让我们讨论一下大家都同意的MVVM模式的标准规则。我也发了帖子 为什么选择MVVM？MVVM标准化,mvvm,Mvvm,MVVM中的某些人目前缺乏标准化，因此每个人都有自己的风格 这就是为什么我和WPF弟子中的几个人正在积极讨论大家都同意的MVVM的哪些元素。我完全理解我们以不同的方式实现了该模式，我们混合了几种模式，或者根据项目的需要创建了我们自己的模式，或者使开发人员的生活更轻松。。但是，忘记那些困难或项目的特殊需要。让我们讨论一下大家都同意的MVVM模式的标准规则。我也发了帖子 为什么选择MVVM？ 测试性（ViewModel比代码隐藏或事件驱动代码更容易进行单元测试） UX设计师和开发者之间的清晰分离
- 测试性（ViewModel比代码隐藏或事件驱动代码更容易进行单元测试）
- UX设计师和开发者之间的清晰分离
- 增加视图的“可混合性”
- 模型永远不需要更改以支持对视图的更改
- ViewModel很少需要更改以支持对视图的更改
- 没有重复的代码来更新视图
- 不应该包含任何您想要测试的逻辑：正如Glenn所说的MVVM不是代码计数练习，我们可以在代码隐藏中编写代码。但是你不应该写任何你想测试的逻辑。例如：如果用户选择一个国家，则您希望在视图中显示州或城市的列表。这是业务需求，因此您应该使用单元测试来测试此逻辑。所以，你不应该在代码后面写
- 可以是控件或数据模板
- 使视图尽可能简单：我们仍然可以小心地在XAML中使用数据触发器、值转换器、可视状态或混合Behivor
- 如果某些内容不可绑定，请使用附加属性：
- 视图和模型之间的连接器
- 保持视图状态，值转换（您可以创建要在ViewModel中显示的数据结构，而不是使用ValueConverter。例如：您需要显示名称，而不是名和姓。您的模型可以有名和姓，但您可以在ViewModel中创建Name属性。）
- 没有强或弱（通过接口）视图参考
- 使VM尽可能可测试（例如，不调用Singleton类）
- VM中没有与控件相关的内容（因为如果您要更改视图，那么您也必须更改VM）
- 可以是数据模型、DTO、POCO、自动生成的域类代理和UI模型，具体取决于您希望在域服务和表示层之间实现分离的方式
- 没有对ViewModel的引用
- MVVM视图直接绑定到ViewModel，并通过数据绑定与VM对话
- 在MVP中，视图绑定到挂起监控控制器的模型，或者根本不绑定（被动视图）
关于这篇文章的全部想法是在社区中获得对MVVM模式的相同理解 我喜欢你写的东西。真正让我头疼的一件事是，很多人的虚拟机似乎与他们的视图紧密地结合在一起——如果你这样做，那么你可能只是在做旧的XAML+所有嵌入代码背后的东西
我使用的模式在MVVM上略有不同（但基本相同）。就我个人而言，我喜欢将我的ViewModel作为一个界面提供给视图——它可以保持分离非常干净。这在制作原型时有很多好处，视觉元素可以在视图中切换或切换，对ViewModel影响很小或没有影响。我认为视图-ViewModel之间通过数据绑定的通信使MVVM成为自己的模式，而不是其他关注点分离。vm通过接口了解视图的好坏并不重要，但在通信所使用的模式的上下文中，它不是MVVM 遗憾的是，获取和维护标准的一些困难在于WPF和Silverlight的缺点和复杂性。然而，当存在多个有效标准时，我会戴上我的Martin Fowler帽子并添加“何时使用”部分 您的标准是否涵盖了本地化等交叉问题 FWIW我喜欢你写的内容，很高兴你把它贴在这里 干杯，
Berryl我认为这个问题应该是一个社区维基。当然。。如何将此问题移至社区Wiki？很抱歉。。有人能帮我搬一下吗？或者请告诉我移动它的方法。谢谢。我想这是t