wpf - 从语义上讲，Commands 和 Converters 应该更接近 Views 还是 ViewModels？

Question

我想知道在 MVVM 中我是否应该将转换器和命令设计得更接近 View 或 View 模型。这对我来说是一个灰色地带，因为它们是弥合组件之间间隙的两种类型的胶水对象。也许这并不重要，但我想知道 Stack Overflow 对此有何评论。

我曾经将 Converters 放在 ViewModel 命名空间中，因为即使 View 发生变化，它们通常也是可重用的。但是，我看到越来越多的评论使它们更接近 View 。查看以下问题的最佳答案:
Should your ViewModel expose XAML elements as properties or not?
How can WPF Converters be used in an MVVM pattern?

命令通常由 ViewModel 公开以实现 UI 事件，因此我也将它们放在 ViewModel 命名空间中。一个经典的例子是 RelayCommands .然后我遇到了一个有趣的模式，即使用命令在主视图和 ViewModel 之间显示对话框。我发现它的简单性非常棒。该命令实际上只是一个代理，但显然在 UI 领域。是还是不是？参见:
MVVM and Dialogs
Handling Dialogs in WPF with MVVM

那么您认为命令和转换器应该放在 MVVM 中的什么位置？看法？ View 模型？没关系？

Answer 1

我认为您不能说他们属于一个阵营或另一个阵营。正如您所说，它们的目的是在 ViewModel 和 View 之间架起桥梁，同时保持它们不耦合。在我看来，这就是您应该如何对待它们，就像胶水代码一样。

转换器 - 您可能会争辩说它们更接近 View ，因为它们的责任与如何调整信息以便轻松绑定(bind)和显示在 xaml 控件中有关。

此外，理论上您可以为同一个 ViewModel 属性使用两个不同的转换器，具体取决于您希望如何查看它。

但是，如果需要，没有什么能阻止您在其他上下文中使用它们，在根本不涉及 View 的地方。

由于您的问题还暗示了将它们放在哪里，我将我的转换器单独放置，既不在 views 文件夹中，也不在 ViewModels 文件夹中，以方便重复使用。

命令 - 通常由 MVVM 中的 ViewModel 公开，因此可以说它们更接近 ViewModel，但根据我的经验，它们最常用于促进调用逻辑通过绑定(bind)的 ViewModel。如果我可以直接在 xaml 中绑定(bind) ViewModel 方法调用，我就不会再使用命令 - 对于简单的情况。

即使它们通常绑定(bind)到 ViewModel，命令也可以在 View 和 ViewModel 之间重复使用。如果您发现自己在复制粘贴命令代码，您可以将它们分开，将 ViewModel 放在接口(interface)后面并重用它们。

此外，命令模式在 MVVM 范围之外还有很多用途。 (例如，您可以在应用程序逻辑中使用它来促进“撤消”功能)

至于将它们放在哪里——通常我先将它们放在 ViewModel 中，随着事情变得越来越复杂，我会根据需要移动它们。这里有一篇有趣的帖子，介绍了当事情变得复杂时您可以做什么:How can I avoid command clutter in the ViewModel?

我知道这是一个主观的答案，但我希望我提供了一些好的论据，并且我愿意接受意见。