Should your ViewModel expose XAML elements as properties or not?
在StackOverflow问题上方,如何在MVVM模式中使用WPF转换器?我了解到,不应在MVVM模式中使用值转换器,因为值转换器的功能应由ViewModel本身处理。
这是有道理的。
但是我记得读过,您不应向视图公开XAML元素,而应仅公开视图然后使用DataTemplates绑定和显示的数据集合。
但是,转换器似乎功能非常强大(例如,在MVVM模板演示中使用它们,解压缩后,请参阅" Messenger示例"),因为它们可以将对象转换为对象,例如消息对象到FlowDocument对象,客户对象到可见性对象,自定义状态对象到图像等。
因此,如果ViewModel要采用值转换器的功能,就必须公开XAML元素和属性,例如StackPanel,Visibility,Color,FlowDocument等,对吗?
是否有人看到ViewModel不像Value Converters那样公开这些丰富的XAML对象的任何原因?
因为那限制了ViewModel仅可用于特定的视觉表示。
一旦ViewModel发出XAML,它将设计内容放入开发人员的域中。
这意味着使用Expression Blend的设计人员无法编辑设计资产-设计人员/开发人员的工作流程已损坏。
将XAML保留在页面上,并将值转换器与数据模板一起使用,可使设计与代码分离。
当您的ViewModel公开特定的XAML时,它还限制了该ViewModel仅在该特定实例中使用,并降低了其可重用性。
不要忘记,您也可以使用DataTemplates。我可以看到让ValueConverters脱离MVVM的某种感觉,但是DataTemplates都是关于将对象转换为GUI的。
您的ViewModel可以向GUI公开其他对象(例如嵌套的ViewModel),并且GUI可以使用
Does anyone see any reason why a ViewModel should not expose these rich XAML objects as Value Converters do?
绝对是因为它破坏了MVVM的所有目标:
如果我看到一个视图模型返回一个视图,我什至不会将其归类为MVVM。
我认为mvvm / mvc / mvp等的一种想法是将GUI代码隔离到一个文件/类。
如果这样做,是否可以在不重写其他对象的情况下切换到其他UI?
我认为,如果您绕过WPF特定对象,答案是否定的。
这是您必须为自己做的价值判断。
当您讨论这些概念或许多其他概念时,没有一个绝对的100%规则适用于您,而无需考虑为什么社区的思想朝这个方向转变了。不管当时有多么新颖或引人注目,"常规智慧"中都没有"假定"的真理或科学。
换句话说,只要在团队中尽最大努力就好,就好像您的善良一样,您已经在人类关注中所遭受的打击远不止于此。