c# - 模型在 "traditional"C#/SQLite MVVM 应用程序中的作用

Question

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

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

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

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

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

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

谢谢

Answer 1

一般来说，模型是一组类，其中包含进入客户端的数据。它可以是 Entity Framework 模型或经典数据集或记录集。它甚至可以是包含 JSON(或其他格式)的字符串。

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

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