最近，我正在学习MVVM设计模式！按照我的方式，我在模型中编写数据库函数，并让视图模型调用模型中的数据库函数，然后viewmodel获取数据库数据并将其设置为viewmodel notfiypropertychanged。这是我目前使用的方式！WPF MVVM模型如何获取数据
有一些问题让我对模型感到困惑， 我读了很多文章告诉我模型只是一个包含数据而不是更多的业务逻辑，这里是我的问题，如果模型只是一个数据容器，我需要让我的viewmodel调用数据库然后获取数据并设置为模型，我认为这种方式非常奇怪，viewmodel代码变得沉重。有没有人有另一种方法来做到这一点？谢谢！
的型号：
“的模式只是一个包含数据，而不是更多的商业逻辑”
模型是描述你的域逻辑中的一个实体类。什么是域名？星巴克的领域是咖啡饮料和员工（其中包括），福特的领域是汽车，装配线和员工。 NYTimes的领域是文章，问题，供应路线，用户等等。
模型包含数据AND逻辑。您可以有多个模型来描述您的域。
您可以将数据呼叫您的模型，但它更常见的有辅助类，数据访问层（DAL），让您的所有数据库调用在一个地方，而不是四处传播他们。
视图模型：
视图模型坐在你的域模型和视图之间。这是一个暴露模型属性并表示视图状态的类。例如，视图模型只能展示UI需要显示的模型中的所有属性的子集，但它也可以添加它自己的属性;用户处于编辑模式？有更改需要保存吗？等与MVVM的卖点就是用户界面结合上这是一种机制来保持UI了解最新的变化，和抽象的这种额外的层视图模型这些特性方便地解耦以任何逻辑模型使它更强大的代码更改方向和可测试。关于这个话题还有更多要说的，但我会留给你看看。
有很多很好的资源和MVVM模式信息;从博客Model-View-ViewModel (MVVM) Explained，微软The MVVM Pattern和这里SO。
如果你喜欢视频，Pluralsight在MVVM模式 Practical MVVM和WPF MVVM In Depths上有很好的视频教程。他们有一个免费的30天试用期。
“只是一个数据容器”
，使得只有持有其传递数据类通常称为数据传输对象（DTO）。通常将它们保持较小并从获取数据库数据方法调用中返回这些集合。
我在这方面做了一些研究，也发现它很混乱。我首先想指出的是代码模式是抽象的。这意味着你有许多不同的方式来实现它/调整它。
大多数人告诉我的是，在“现实生活”的应用程序中，您通常会拥有多层服务。
其中一项服务是您从数据库获取数据的位置。
模型工作（在我看来）是为开发人员提供关于数据库数据和结构的知识。一个模型到一个数据库表格。 它还有助于在将数据发送到数据库之前检查数据是否正确（格式检查，数据类型等）。
关于如何使用模型没有明确的答案。我已经看到了大量不同的实现，并且它们都已经实现了特定的任务。
是的，它可能会出现一些ViewModel变得重载代码和函数来执行，但它可能不是因为代码模式。这可能是因为代码结构不良。在我现在的工作中，我发现了一个包含3000多行代码的ViewModel（这是非常重要的）。这可以很容易地分成至少3种不同的ViewModels和Views，但正如我所说的，糟糕的代码结构会导致问题。
有一件事我建议您在阅读起来是
希望这有助于在某种程度上解释你的问题。
我看了很多文章说告诉我，模型只是一个包含数据，而不是更多的业务逻辑
模型可以通过服务，数据库访问层或业务层因此没有任何表示你目前的做法有误。业务逻辑确实属于模型。
但有时人们往往指的是“孩子”式的一种模式。例如，如果您的视图模型公开List<Item>属性，则Item类可能会被视为模型。也许你的困惑来自于此。
这种类（Item）通常实现INotifyPropertyChanged接口来提供更改通知，并且实际上只是不包含任何业务逻辑的“嵌套”视图模型。
希望是有道理的。
是否使用'.NET Core'？ – aaronR
我没有很多的时间，但现在看，如果这[微软文档（https://msdn.microsoft.com/en-us/library/gg405484（V = pandp.40）的.aspx）帮助。 – aaronR
我不知道你从哪里得到*“模型只是包含数据而不是更多的业务逻辑”，但对我来说，业务逻辑是模型的一部分。但是，我观察到业务逻辑倾向于我的项目的视图模型，我不能说这是否是一件坏事。 – grek40