C# 模型持久性-这种情况应该发生在哪里？

我的问题是关于MVVM中的第一个“M”，即模型。我看到了很多关于如何实现模型的变化。有些只是POCO，没有业务逻辑和持久性逻辑，而另一些则包含一个或两个逻辑

现在，在我们的应用程序中，我们在模型、视图和视图模型之间进行了适当的分离。这是我们当前的解决方案结构（它是WPF prism应用程序）：

• 基础设施
• 模块A
  • 视图模型
  • 观点
• 模块B
  • 视图模型
  • 观点
• 模型（在模块之间共享，这就是为什么它在自己的类库中）
• 服务
• 数据访问（可能使用简洁的点网）
• 壳牌（主要WPF项目）

我们现在需要弄清楚如何对数据库执行CRUD并保持模型的更新。我喜欢这样的想法，即保持模型非常简单，拥有一个“服务”类库，其中包含我们的业务逻辑，并针对我们的数据访问类执行一个工作单元模式。保持模型沉默和对业务逻辑/数据访问一无所知是否存在任何已知问题？这在MVVM中很少见吗

我想知道，如果不在模型中放置一些逻辑，例如，从给定参数的ctor中加载模型，是在限制自己还是使事情变得比需要的更复杂。请注意，这将是一个大型应用程序

我们的应用程序必须将模型持久化到多个数据库。我们使用Unity作为我们服务的依赖注入容器。您建议我如何告诉服务使用哪种数据连接？每一个函数等

---

在我看来，MVVM模型只是“代表”数据，因此不应该有任何逻辑、CRUD或其他嵌入。您已经有了数据访问层，因此在那里编写CRUD代码并使用DI从您的模型访问此CRUD代码是完全正常的

MVVM的“美”在于它可以被解释，所以我相信其他人会认为模型就是数据，它可以包含CRUD逻辑

---

我的DAL中有我所有的CRUD操作，我还没有看到这种方法的缺点…

此外，MVVM不是一种应用程序架构模式，但它是一种以更标准化的方式设计用户界面的模式。因此，在数据方面，MVVM不是选择的手段。谢谢。最后，我使用了工作单元模式，并将服务/存储库放在所有这些之上，以填充和持久化我的模型。