我的问题是关于模型 MVVM 中的第一个“M”。我看到了很多关于如何实现模型的变化。有些只是没有业务逻辑和持久性逻辑的 POCO，而另一些则包含一个或两者。
现在，在我们的应用程序中，模型、视图和视图模型之间有很好的分离。这是我们当前的解决方案结构（它是一个 WPF prism 应用程序）：
- 基础设施
- 模块 A
- 视图模型
- 意见
- 模块 B
- 视图模型
- 意见
- 模型（在模块之间共享，这就是它在自己的类库中的原因）
- 服务
- DataAccess（可能使用 dapper-dot-net）
- Shell（主要 WPF 项目）
我们现在需要弄清楚如何对数据库执行 CRUD 并保持模型更新。我喜欢保持模型非常简单的想法，并拥有一个“服务”类库，其中包含我们的业务逻辑并针对我们的数据访问类执行一个工作单元模式。保持模型愚蠢和不了解业务逻辑/数据访问是否存在任何已知问题？这在 MVVM 中很罕见吗？
我想知道我是否通过不在模型中放置一些逻辑来限制自己或使事情变得比需要的更复杂，例如，在给定参数的情况下从其 ctor 中加载模型。请注意，这将是一个大型应用程序。
我们的应用程序必须将模型持久化到多个数据库。我们使用 Unity 作为我们服务的依赖注入容器。你会如何建议我告诉服务使用哪个数据连接？Tor，每个功能等？
有点想寻找建造类似结构的人，以及他们的经验/建议是什么。