我正处于必须对模型做出决定的地步。我知道模型是您用来进行所有数据库操作的工具。但是模型是否仅限于此？
它们仅用于数据库交互还是用于所有外部数据操作（例如来自外部 API 的数据等）？
【问题讨论】：
标签： model-view-controller model
MVC 范例是一种设计模式，您可以在其中使用以下结构组织应用程序。
模型：这是您应该保存数据模型和算法的地方。例如，如果您编写电子表格应用程序，您将保留电子表格的数据结构。您将在模型中拥有计算引擎，您将拥有在模型中保存和加载电子表格的代码。这些模型类可能会在其他应用程序中重用，例如，如果您有代码来进行数据压缩。
一个或多个视图：这些是用于可视化数据（UI）的代码部分，对于电子表格，您有一个典型的电子表格视图，其中包含单元格 A1 到 Z100 等。您还可以使用图表视图来可视化您的数据.等等。 视图也可以在其他应用程序中重复使用，例如您可以重复使用您喜欢的图表视图。
控制器将视图连接到模型。这可能是最不可重用的部分，控制器知道模型，知道要显示哪些视图。通常，控制器将设置用户与应用交互时视图将调用的回调。然后控制器将从模型中获取信息并更新视图。
如果您遵循这些准则，您可能能够更改您的模型，例如从将文件保存到磁盘的模型更改为在不更改 UI 的情况下将文件保存在云中的模型......理论上。您还可以在不更改模型的情况下添加新视图。您还可以为您的模型编写单元测试或回归测试。
没有严格的规定，最好是用常识和自己的判断。
【讨论】：
例如，在 Django 中，模型是一个映射到数据关系（表）和潜在桥接表（例如，用于多对多关系）的类。
同一个类可以有对相应数据进行操作的方法，也可以有其他类不是自己定义模型，而是访问和过滤数据的方法。
但 MVC 中的术语模型确实适用于描述数据结构和一般访问它们的方法。
这些框架可能在某种程度上扭曲了抽象术语。例如，Django 调用的视图实际上是控制器函数，定义表示的实体称为模板，而不是视图。
【讨论】：
不，它们不仅限于数据库访问。
在 MVC 应用程序中，M 通常是您的域的模型。这意味着它可以封装业务逻辑和数据。我建议您避免使用anaemic domain model。您甚至可以将模型设置为对持久性无知。要了解我的意思，请查看Crafting Wicked Domain Models 上的此演讲。
在视图和控制器方面，我建议始终使用所谓的视图模型，即使它感觉像是一对一的映射。迟早你会发现模型实际上是不同的，你不想让 View 承担比将简单的 View Model 直接翻译成 HTML 或其他渲染格式更多的责任。
然后，控制器的工作就是在您的模型上执行行为并为视图创建视图模型。
【讨论】：
不要将模型与数据库相关联。将其视为您当前使用的数据的内存表示（对于当前未使用的数据，可能在数据库中，当您访问该数据时，它首先会到达模型，然后传播到应用程序的其他部分.)。当您完成数据操作（您在模型中执行的操作）后，您可以将其保存到数据库以供以后使用。此外，Model 是第一个在您从 DB 中检索数据时从 DB 中获取数据的类。
【讨论】：
对我来说，简单的解释是：
View 这是一个创建请求并接收响应并可视化界面的实体。
控制器 这是位于视图和模型之间的实体。这是一个实体，它接收 View 的请求并返回响应。
Model 处理所有其余的工作。这意味着处理请求、处理数据、创建对象、调用外部 API、访问数据库等。
如果您移除控制器并查看系统，剩下的就是模型。
所以 Model 不仅仅是数据模型或业务逻辑模型。它还可能包含其他部分，如安全、验证、处理、过滤等。
【讨论】：