Model view controller 在MVC应用程序中，控制器或模型应该处理数据访问吗？

我们公司正在进行一些哲学上的辩论，讨论在哪里调用业务逻辑来执行CRUD操作

我相信模型应该由您的数据结构组成，控制器应该负责填充数据

我的同事认为，所有填充都应该在模型类本身中完成，并由控制器简单地调用。这使控制器保持整洁（但在我看来，会使模型变得杂乱无章）

他还认为，任何返回Json对象的调用都应该发生在模型中，而不是控制器中。模型将向控制器返回一个数组，然后控制器将该数组作为Json对象返回

---

每个模型有哪些不同的优点/缺点？有正确或错误的方法吗？

模型应该处理数据访问

发件人：

模型。模型对象是应用程序中实现 应用程序数据域的逻辑。通常，为对象建模 在数据库中检索并存储模型状态。例如，一个产品 对象可能从数据库检索信息，对其进行操作，然后 然后将更新的信息写回SQL中的Products表 服务器数据库

---

所有业务逻辑都应该在模型中

请记住，每一层的职责如下：

• 控制器-模型和视图之间的桥梁。决定下一步去哪里
• 视图-显示数据，收集用户输入

---

• 模型-业务逻辑，数据存储接口

最大的收益之一是维护和（以后）扩展。一般而言：

• 如果需要更改业务逻辑，则不需要修改控制器或视图
• 如果更改视觉显示，则不需要修改模型或控制器
• 如果更改工作流，则不需要修改视图或模型

为了完成上述工作，每一层都应该不了解其他层，以便正常工作。例如，视图应该接收数据，而不需要知道数据来自何处，以便正确显示数据。为了与模型交互，控制器不需要了解模型的底层结构。模型应该不知道数据将如何显示（例如，格式化）或工作流

“他还认为，任何返回Json对象的调用都应该发生在模型中，而不是在控制器中。模型将向控制器返回一个数组，然后控制器将该数组作为Json对象返回。”

不可以。模型不应该格式化数据。它也不应该读取格式化数据。这会污染模型，并进入地狱级别，在那里

业务逻辑=显示逻辑

JSON（输入或输出）只是另一个视图。所以走出去：

Data Store -> Model -> Controller -> View

进来：

View -> Controller -> Model -> Data Store

---

在MVC中，模型负责处理数据访问。其优点是所有数据访问代码都由模型进行逻辑封装。如果在控制器中包含数据访问代码，则会使控制器膨胀并破坏MVC模式。

控制器方法应尽可能精简，这意味着数据访问属于模型（或者更具体地说，是存储库对象）

把你的控制器方法想象成一个开关站。。。他们只负责将任务委托给其他方法执行

如果您正在控制器中编写任何Linq代码，那么您将创建一个依赖项，如果您的站点结构发生更改，则必须修改该依赖项，并且您可能会复制数据访问代码。但是模型中的

GetCustomer

仍然是

GetCustomer

，无论从控制器调用它的位置如何。这有意义吗

比简单地访问数据更广泛的业务逻辑可以放在它自己的业务逻辑层中，业务逻辑层被认为是模型的一部分

我对JSON不是很确定。JSON只是另一种数据表示形式；如果您有一个实用方法可以将数据类转换为JSON，请从模型中调用

GetCustomer

，并在控制器方法中执行到JSON的转换

仅供参考，我的主要语言是PHP，因此您可以对此持保留态度

MVC和受MVC启发的模式中的业务逻辑必须位于模型层。是的，模型应该是一个层，而不是一个类或对象

所述逻辑的大部分将驻留在中，但其中一些将最终位于中，这应该类似于模型层中的“顶级”结构，通过它表示层（视图和控制器）与模型层交互

服务还应促进存储抽象（、和/或）与域对象之间的交互。这些结构将处理持久和临时存储，并处理数据完整性

这种分离简化了代码库的维护和测试。您可以轻松地测试域逻辑，而无需接触数据库（或任何其他形式的存储）

控制器（以及其他MVVM和MVP模式的等效结构）应该从用户请求中提取信息，并更改模型层的状态（通过使用服务）和视图

如果实现MVP或MVVM，则类似控制器的组件将承担额外的责任，包括从模型层到视图的数据传输，但在经典和Model2 MVC模式中，视图应为活动结构，从模型层请求数据

至于JSON的生成，实际上应该在视图中进行。视图应该包含全部（或大部分），这取决于您使用模板的方式