模型持久性 - 应该在哪里发生

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

现在，在我们的应用程序中，我们在模型、视图和视图模型之间有一个很好的分离。这是我们当前的解决方案结构（它是一个 WPF 棱镜应用程序）：

• 基础设施
• 模块 A
  • 视图模型
  • 视图
• 模块 B
  • 视图模型
  • 视图
• 模型（在模块之间共享，这就是为什么它在自己的类库中）
• 服务业
• DataAccess（可能利用dapper-dot-net）
• 命令行管理程序（WPF 主项目）

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

我

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

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

有点寻找建立类似结构的人，以及他们的经验/建议是什么。