MVC中的模型是View显示的业务逻辑或数据

Question

和其他许多人一样，我在理解MVC模式方面遇到了问题。更准确地说，让我们谈谈Grail网络应用程序。我的理由是模型是服务和域类。控制器的典型用法是（实际上对于这种特殊用法，我们可以直接从控制器调用Person.get（id），但假设我们通过服务进行调用）：

def getPerson(String id){
    Person person = peopleService.get(id);
    render(view: "person", model: person)
}

在这种情况下，事实证明服务方法已返回域对象，以防万一是Model的一部分。但可能是服务方法不修改域对象或修改域对象，但返回布尔值。

def savePerson(Person p){
    boolean saved = peopleService.save(p);
    render(view: "actionresult", model: saved)
}

在这种情况下，布尔值不是Model的一部分，但是它在render方法中被命名为model。

所以我有三个假设：

• 有两种模型：负责业务逻辑的应用程序层模型和用于呈现视图的数据
• MVC是完全呈现层模式，与业务逻辑层无关，在这种情况下，模型只是视图显示的数据
• 模型是服务层和域类，控制器通过服务方法调用触发模型更新，用于渲染视图的数据应该以某种方式表示模型状态，这就是为什么它在渲染函数中也称为模型

你怎么看？

Answer 1

我会说你的假​​设是正确的 - MVC可以在不同的背景下表达不同的东西。当您基于MVC模式创建MVC框架或应用程序时，您还可以定义“模型”在该上下文中应该是什么。例如，它可以是复杂的域模型，也可以只是数据访问层。

我认为可以肯定地说，在使用通用MVC框架构建的复杂Web应用程序的上下文中，“模型”不一定与业务逻辑模型相同。网上商店中“产品”的基本商业模式可以包含有关供应商和购买价格的信息，例如，您可能永远不想在网上商店界面中公开这些信息。

因此，在这种情况下，您可能希望使用一个不同的“模型”，将一些（但不是全部）属性暴露给MVC框架。

有一个名为MVVM的概念明确地考虑了这一点。简单地说，“视图模型”是“适当”模型的映射，用于在特定视图中显示。

Answer 2

Grails在分离不同层时非常清楚。

非常简单，在Grails世界中：

M：模型是您的Domain类，用于为数据层建模（表格，集合等）

V：视图是您的gsp页面或您的表示层

C：控制器是路由器，将责任分配给其他类，但是，它们很容易被滥用于其他职责。

Services只是帮助您的业务逻辑的辅助类，具有特殊的特征（事务等）。