我的问题是关于 MVVM 模型中的第一个“M”。我看到关于如何实现该模型的大量变化。有些只是 POCO，没有业务逻辑和持久性逻辑，而另一些包含其中之一或两者。
现在，在我们的应用程序中，模型、 View 和 View 模型之间有一个很好的分离。这是我们当前的解决方案结构(它是一个 WPF Prism 应用程序):
- 基础设施
- 模块A
- View 模型
- 浏览量
- 模块 B
- View 模型
- 浏览量
- 模型(在模块之间共享，这就是它在自己的类库中的原因)
- 服务
- DataAccess(可能利用 dapper-dot-net)
- Shell(主要 WPF 项目)
我们现在需要弄清楚如何对数据库执行 CRUD 并保持我们的模型更新。我喜欢这样的想法，即保持模型非常简单，并拥有一个包含我们的业务逻辑并针对我们的数据访问类执行工作单元模式的“服务”类库。保持模型的愚蠢和不了解业务逻辑/数据访问是否存在任何已知问题？这在 MVVM 中很少见吗？
我想知道我是在限制自己还是让事情变得比他们需要的更复杂，因为没有在模型中放置一些逻辑，例如，在给定参数的情况下从其 ctor 中加载模型。请注意，这将是一个大型应用程序。
我们的应用程序必须将模型持久化到多个数据库。我们使用 Unity 作为我们服务的依赖注入(inject)容器。你会如何建议我告诉服务使用哪个数据连接？ Ctor、每个函数等？
有点在寻找建立了类似结构的人，以及他们的经验/建议。
最佳答案
在我看来，MVVM 模型只是“表示”数据，因此不应包含任何逻辑、CRUD 或其他嵌入的内容。您已经拥有数据访问层，因此在那里编写您的 CRUD 代码并使用 DI 从您的模型访问此 CRUD 代码是完全正常的。
MVVM 的“优点”在于它可以解释，所以我敢肯定其他人会争辩说模型就是数据并且它可以包含 CRUD 逻辑...
我的所有 CRUD 操作都在我的 DAL 中，但我还没有看到这种方法的缺点...
关于c# - 模型持久性——应该在哪里发生？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10821376/