我正在尝试掌握 MVVM，因此我阅读了大量文章 - 大部分关注 View -> ViewModel 关系，并且对什么是什么达成了普遍共识。 ViewModel -> Model 关系以及 Model 的组成部分关注度较低并且存在分歧。我很困惑，想要一些帮助。例如，this article将模型描述为业务对象，而 this article描述了一个管理业务对象的类。这些是正确的还是别的什么？
最佳答案
我认为你在正确的轨道上。 “模型”含糊不清 在很多情况下因为对别人来说是不同的东西 ，理所当然。
对我来说，我的生意从我的 WCF 服务返回的对象 我认为我的模型 .因为这个我的项目没有那种带有三位一体命名空间的漂亮文件结构: *.Models、*.ViewModels 和 *.Views。我个人考虑从业务逻辑返回的对象 或任何类似性质的东西 “模型” .
一些 人们倾向于将业务对象和业务逻辑混为一谈 并将其称为“模型”，但是 我觉得有点困惑因为我认为模型比业务逻辑更静态，但是 它的语义 .
因此，当您查看 MVVM 项目的示例时，并没有很清楚地看到任何“模型”，这只是因为人们对待它们的方式不同。除非应用程序非常独立，我实际上会非常怀疑具有实际 *.Model 命名空间的应用程序 ， 老实说。
另一件很棒的事情是，很多时候您已经对这些类型的业务对象进行了投资，我认为很多人看到“MVVM”并立即认为他们需要开始定义“M”，即使他们已经有了就很好了。
Model 和 ViewModel 之间的混淆也很常见。本质上如果我需要数据和行为的组合，我知道我需要一个 ViewModel .例如，我不希望在模型上实现 INotifyPropertyChanged，但我希望在 ViewModel 上实现。
关于silverlight - MVVM 中的模型 : business object or something else?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1876274/