WPF、MVVM、ICommand 和存储库答案

【问题标题】：WPF, MVVM, ICommand, and repositoriesWPF、MVVM、ICommand 和存储库
【发布时间】：2017-01-03 23:07:29
【问题描述】：

我有一个看起来像这样的 WPF 应用程序：

viewmodel 包装模型并通过 INotifyChanged 公开与视图相关的任何属性。该视图还绑定到几个 ICommand 对象，这些对象处理视图触发的某些行为。我有一个外部 ICommand，其唯一目的是将模型保存到数据库中。

我读过的所有内容都表明视图或视图模型都不应该引用存储库。这就是视图模型之外的命令 3 的原因。

我的问题是双重的。首先，这是一个合理的架构，其次，有什么好方法可以将模型实例传递给命令 3，以便将其放入存储库中？

【问题讨论】：

Command 1 和 Command 2 在 VM 中以及 Command 3 在 VM 中的具体情况如何？不是所有命令都在它们自己的类中单独实现，并且只是作为其属性“添加”到 VM 中吗？在这种情况下，一个命令在 VM 中，另一个命令在 VM 中？？

【解决方案1】：

我个人认为让 ViewModel 引用存储库没有问题。试图避免这种情况会导致不必要的并发症。

在 MVVM 中，ViewModel 通常是位于模型之上的“粘合”层 - 存储库是模型的一部分（它是特定领域数据/逻辑的一部分）。我个人对此的看法blog series on MVVM shows a good image：

通过将命令 3 放入 VM 让 VM 直接使用存储库可能比尝试将其分离出来更干净。

【讨论】：

我只想在 Reed 所说的基础上添加一点内容：如果您愿意，您当然可以通过抽象出存储库的细节来将其解耦。但我同意，没有理由按照图表显示的方式将它们完全分开。
@Tim 好点。抽象出存储库细节非常有用，但几乎是一个单独的问题（非常适合可测试性等）。
我同意这是一个单独的问题，但我有点想知道这种抽象是否可能是 OP 听证会背后的原因，他应该将它们解耦。只是想回答“那么为什么[谁]说如果我不需要我应该这样做？”在他问之前先问！
@Tim 我怀疑你可能是对的。我发现很多时候，当人们谈论 MVVM 时，他们会包含很多不是真正 MVVM 的问题。大多数“框架”包含大量非常好的和有用的代码，但真正将关注点与核心架构模式分开。我认为这让刚接触 MVVM 并试图理解它的人的生活变得非常混乱。
谢谢，这是一个很好的答案。我们的存储库已经被抽象到它自己的类中。现在对我来说，为什么有人会说不要在视图模型中包含存储库“代码”（sql 语句等），而不是包含对抽象存储库类的引用，这对我来说是有道理的。

【解决方案2】：

视图模型应该与业务层（域对象 + 域服务）而不是直接与存储库通信。更进一步，这种通信应该通过命令来完成。

所以你有：

视图 -> 视图模型 -> 命令 -> 域对象/域服务 -> 存储库

除非你正在开发一个非常简单的 CRUD 应用程序......

【讨论】：