您的 ViewModel 是否应该将 XAML 元素公开为属性？
关于 StackOverflow 问题如何WPF 转换器可以在 MVVM 模式中使用吗？我了解到，值转换器不应该在 MVVM 模式中使用，因为值转换器的功能应该由 ViewModel 本身处理< /强>。
这是有道理的。
但我记得读过，您不应该向视图公开 XAML 元素，而应仅公开数据集合，然后视图使用 DataTemplates 绑定并显示这些数据集合。
然而，转换器似乎非常强大（例如，因为它们在 MVVM 模板中使用demo，解压后参见“Messenger Sample”），它们可以将对象转换为对象，例如 Message 对象转换为 FlowDocument 对象，或者 Customer 对象转换为 Visibility 对象，或者自定义 Status 对象 等
因此，如果 ViewModel 要承担值转换器的功能，它就必须公开 XAML 元素和属性，例如 StackPanel、Visibility、Color、FlowDocument 。， 正确的？
有人知道为什么 ViewModel 不应该像值转换器那样公开这些丰富的 XAML 对象吗？
Over at the StackOverflow question How can WPF Converters be used in an MVVM pattern? I've learned that Value Converters should not be used in the MVVM pattern since the functionality of a Value Converter should be handled by the ViewModel itself.
This makes sense.
But I remember reading that you should not expose XAML elements to the View, but instead expose only collections of data which the View then binds and displays using DataTemplates.
However, converters seem quite powerful (e.g. as they are used in the MVVM Template demo, see the "Messenger Sample" after unpacking it) in that they can convert objects to objects, e.g. Message objects to FlowDocument objects, or Customer objects into Visibility objects, or custom Status objects into Images, etc.
So if a ViewModel is going to take on the functionality of a Value Converter, it is going to have to expose XAML elements and properties such as StackPanel, Visibility, Color, FlowDocument, etc., right?
Does anyone see any reason why a ViewModel should not expose these rich XAML objects as Value Converters do?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
因为这样就限制了 ViewModel 只能与特定的视觉表示一起使用。
一旦 ViewModel 发出 XAML，它就会将设计内容放入开发人员的域中。
这意味着使用 Expression Blend 的设计人员无法编辑设计资源 - 并且设计人员/开发人员工作流程被破坏。
将 XAML 保留在页面上并使用带有数据模板的值转换器可以使设计与代码分离。
当您的 ViewModel 公开特定的 XAML 时，它还会限制 ViewModel 只能在该特定实例中使用，并降低其可重用性。
Because then that limits the ViewModel to be used only with a specific visual representation.
Once you have the ViewModel emitting XAML, it puts design content into a developer's domain.
This means that the designer using Expression Blend cannot edit design assets - and the designer/developer workflow is broken.
Keeping the XAML on the page and using Value converters with data templating keeps the design separated from the code.
When your ViewModel exposes specific XAML it also limits that ViewModel to be used only in that specific instance and makes it less reusable.
不要忘记您也可以使用 DataTemplates。 我认为将 ValueConverters 排除在 MVVM 之外是有道理的，但 DataTemplates 的作用就是将对象转换为 GUI。
您的 ViewModel 可以向 GUI 公开其他对象（例如嵌套的 ViewModel），并且 GUI 可以使用
... Don't forget that you can use DataTemplates too. I can see some sense in keeping ValueConverters out of MVVM, but DataTemplates are all about transforming objects into GUI.
Your ViewModel can expose other objects (e.g. nested ViewModels) to the GUI, and the GUI can use
<DataTemplate DataType="{x:Type SubViewModel}">...to map those objects to GUI.绝对可以，因为它破坏了 MVVM 的所有目标：
如果我看到视图模型返回视图，我什至不会将其归类为 MVVM。
Absolutely, because it undermines all the goals of MVVM:
If I saw a view model returning a view, I wouldn't even classify it as MVVM.
我认为 mvvm/mvc/mvp 等的想法之一是将 GUI 代码隔离到一个文件/类。
如果这样做，您可以更改为其他 UI 而无需重写其他对象吗？
我认为如果您传递 WPF 特定对象，答案是否定的。
这是你必须为自己做出的价值判断。
I think one idea of mvvm/mvc/mvp etc. is to isolate the GUI code to one file/class.
If you do this can you change to some other UI without rewriting the other objects?
I think if you're passing around WPF specific objects the answer is no.
It's a value judgment you'll have to make for your self.
当你讨论这些概念时，如果不了解为什么社区的思想会朝这个方向转变，那么没有绝对的 100% 规则适用于这个概念或许多其他概念。 “传统智慧”中不存在“假定的”真理或科学，无论它在当时多么新颖或令人信服。
换句话说，只要和你的团队一起尽力而为，就好像你的利益一样，你已经因为人类的担忧而被拉低了，而不是像这样真实的事情。
There is no absolute 100% rule that works for this or many other concepts when you discuss them without the perspective of why the community's mind has shifted as it has in this direction. There is no 'assumed' truth or science in 'conventional wisdom' regardless of how new or compelling it is at the time.
In other words - just do the best with your team as if your good, your already getting pulled down far more in human concerns than anything as real as this.