我的问题是关于MVVM中的第一个“M”，模型。我看到了如何实现模型的大量变化。有些只是POCO，没有业务逻辑，没有持久性逻辑，其他包含一个或两个。
目前，在我们的应用程序中，我们在模型，视图和视图模型之间进行了适当的分离。这是我们当前的解决方案结构（它是WPF棱镜应用程序）：
我们现在需要弄清楚如何对数据库执行CRUD并保持模型更新。我喜欢保持模型非常简单，并且拥有包含业务逻辑的“服务”类库，并针对我们的数据访问类执行工作单元模式的想法。是否存在任何已知的问题，使模型保持愚蠢和无知的业务逻辑/数据访问？这在MVVM中是不常见的？
我想知道我是不是通过在模型中放置一些逻辑来限制自己或使事情变得比他们需要的更复杂，例如，在给定参数的情况下从其内部加载模型。请注意，这将是一个很大的应用程序。
我们的应用程序必须将模型保存到多个数据库。我们使用Unity作为我们服务的依赖注入容器。您如何建议我告诉服务使用哪种数据连接？ Ctor，每个功能等？
有点寻找建立类似结构的人，以及他们的经历/建议是什么。
答案 0 :(得分：5)
在我看来，MVVM模型只是“代表”数据，因此不应该有任何逻辑，CRUD或其他嵌入。您已经拥有数据访问层，因此在那里编写CRUD代码并使用DI从模型访问此CRUD代码是完全正常的。
MVVM的“美丽”是它可以解释，所以我相信其他人会认为模型是数据而且它可能包含CRUD逻辑......
我在DAL中完成了所有CRUD操作，并且还没有看到这种方法的缺点......