模型在“传统”C#/SQLite MVVM 应用程序中的作用答案

【问题标题】：Role of the model in a "traditional" C# / SQLite MVVM app模型在“传统”C#/SQLite MVVM 应用程序中的作用
【发布时间】：2014-08-26 07:30:03
【问题描述】：

根据a separate thread 中的回复，我担心我在学习这些内容时错过了 MVVM 的基本原理。我得到了关于视图绑定到视图模型、通知等的更简单的东西。底层技术方面对我来说很有意义。不太清楚的是视图模型和模型之间的界限在哪里。

我正在尝试构建一个通用的一切（我现在的重点是 Windows Phone 部分）。我将使用 SQLite 来持久化和检索数据。而这个简单的方面是我不清楚的地方。

我曾假设我编写的类将形成“模型”，而这些类将负责从 SQLite 检索数据。视图模型将绑定到模型类的属性，视图将绑定到视图中的属性。作为这一切的一部分，我假设与 SQLite 的所有交互都在我的模型中。

现在，根据单独线程中的评论，我担心我错了。声明是视图模型将负责“加载”模型。它 - 而不是模型 - 可能会直接与 SQLite 交互。

嗯，这对我的理解产生了影响，现在我想知道我是否一直错过了穿过树木的树林 :) 在我的简单应用程序中，模型层是什么？ SQLite 本身可以被认为是模型，视图模型直接与 SQLite 交互。如果是这样，我可能编写的模型类的作用是什么 - 如果我的需求很简单（CRUD 到 SQLite），那么我需要模型层的类？

虽然我知道没有一种“正确”的方式来设计这样的应用程序，但我想确保我遵循基本的、公认的原则。考虑到这一点，在“简单”的 MVVM / SQLite 应用程序中，稍后的模型究竟是什么？

谢谢

【问题讨论】：

你能用你提到的线程的链接更新问题吗？
@venerik - stackoverflow.com/questions/25499037/…

标签： c# sqlite mvvm viewmodel

【解决方案1】：

一般来说，模型是一组类，其中包含进入客户端的数据。它可以是实体框架模型或经典数据集或记录集。它甚至可以是一个包含 JSON（或其他格式）的字符串。

一般来说，我接受模型由数据源决定。我按原样使用它，当它由于数据源的变化（规范化、协议更改、新版本）而发生变化时，我会在 ViewModel 中调整从 Model 到 ViewModel 的转换。

因此，Data Source 的更改只会影响 Model 和 ViewModel 中的转换逻辑。 ViewModel 的界面和 View 应该尽可能稳定，因为这些应该由用户需求驱动。当然，除非 Model 中的更改也是为了在 View 中提供新功能，在这种情况下，ViewModel 和 View 需要更改以显示新数据。

【讨论】：

再次感谢您，厄诺。这就说得通了。我试图在跨视图、视图模型和模型的良好“理论”设计与允许我快速有效地开发我的应用程序的实用方法之间取得平衡，同时还允许我以合乎逻辑的方式在未来。这里重要的一个因素是我正在尝试构建一个非常（非常！）简单的应用程序。它不是“企业”应用程序可以扩展、适应各种部署和设计变更等等。它只是一个带有本地数据库 (SQLite) 的 Windows Phone 应用程序。
因此，我的目标是使用 MVVM，同时对关注点隔离等理论保持务实。考虑到这一点，提出一个更具体的问题。对于一个在本地 SQLite 实例中访问其所有数据的简单应用程序，将 SQLite 视为模型是否合理 - 即 viewmodel 创建数据库（通过 SQLite API），通过 QueryAsync() 查询数据等。换一种说法方式，我真的需要模型层中位于视图模型和 SQLite 之间的一组类吗？
由于 SQLite 是“模型”，我仍然可以在视图和视图模型（视图模型处理转换等）之间建立稳定的“契约”。
我会将 SQLite 视为数据源，而不是模型。 odel 将是我从用于从 SQLite 检索数据的 API 获得的任何数据结构。不要太担心它。没有人会强迫你需要任何东西。 MVVM 只是一种模式。根据需要使用它。拥有 Model 类可以让您更轻松地在数据源之间切换，例如进行单元测试。
再次感谢您，厄诺。这对我来说是一个有趣的（坦率地说，很有趣）的调查，因为我试图找到平衡点。与您不被 MVVM 的“纯度”所挟持的暗示一致，我决定不使用明显的模型层。请记住，这不是一个企业应用程序（甚至不是一个特别复杂的应用程序），我让视图模型直接与 SQLite 交互。我理解概念上的不一致，但我发现自己在视图模型和模型类中复制（例如）“项目”表示。