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

Question

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

我相信模型应该包含您的数据结构,并且控制器应该负责填充数据.

我的同事认为所有人口都应该在模型类中完成,并且只需要由控制器调用.这使控制器整洁干净(但在我看来,这会使模型变得混乱).

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

每个人有什么不同的利弊,是否有正确或错误的方法来做到这一点？

Answer 1

所有业务逻辑都应该在MODEL中.

请记住,每个层的职责是:

• 控制器 - 模型和视图之间的桥梁.决定下一步去哪儿.
• 查看 - 显示数据,收集用户输入
• 模型 - 业务逻辑,数据存储的接口.

最大的收获之一是维护和(后期)扩展.一般来说:

• 如果需要更改业务逻辑,则不需要修改控制器或视图.
• 如果更改可视显示,则无需修改模型或控制器.
• 如果更改工作流程,则无需修改视图或模型.

要做到这一点,每个层应该不了解其他层才能正常工作.例如,视图应该接收其数据,而不需要知道它来自何处以便正确显示它.该控制器不应该需要了解模型的基本结构,任何为了与它进行交互.该模型应该没有的数据是如何被显示的知识(如格式化)或工作流程.

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

没有.模型绝不应该格式化数据.它也不应该读取格式化数据.那污染模型并进入地狱的水平business logic = display logic.

JSON(进入或出去)只是另一种观点.出门:

Data Store -> Model -> Controller -> View

进来:

View -> Controller -> Model -> Data Store

Answer 2

_{仅供参考,我的主要语言是PHP,所以你可以用这一切来解决这个问题.}

MVC和MVC模式中的业务逻辑逻辑必须位于模型层中.是的,模型应该是一个层,而不是一个类或对象.

大多数所述逻辑将驻留在域对象中,但其中一些最终会出现在服务中,这应该与模型层中的"顶层"结构类似,表示层(视图和控制器)通过它与模型层交互.

服务还应促进存储抽象(数据映射器,数据访问对象,工作单元和/或存储库)与域对象之间的交互.这些结构将处理持久和临时存储并处理数据完整性.

这种分离简化了代码库的维护和测试.您可以轻松测试域逻辑,而无需触及数据库(或任何其他形式的存储).

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

如果您实现MVP或MVVM,那么类似控制器的组件将承担额外的职责,包括从模型层到视图的数据传输,但在经典和Model2 MVC模式中,视图应该是一个活动结构,它从模型请求数据层.

至于JSON的生成,实际上应该在视图中发生.视图应该包含所有(或大多数,取决于您使用模板的方式)表示逻辑.它应该从模型层(直接或通过中间人)获取信息,并根据该信息生成响应(有时从多个模板创建它).JSON只是一种不同的响应格式.

_{2005年发布的Rails框架产生了巨大的影响(并且主要是负面影响).它的最初目的是成为一个原型构建框架 - 快速创建一个抛弃代码.为了实现这一目标,他们将模式简化到了关注点分离被打破的程度.}

_{他们用活动记录结构的集合替换了模型层,这很容易生成并合并控制器中的视图功能,使模板可以替代完整的视图.它是初始目标的完美解决方案,但是,当它开始在其他领域传播时,引入了大量关于MVC和MVC启发的设计模式的误解,比如"视图只是模板"和"模型是ORM".}

Answer 3

您的控制器方法应尽可能薄,这意味着数据访问属于模型(或更具体地说,属于Repository对象).

将您的控制器方法视为切换场......他们只负责将任务委托给其他执行方法.

如果要在控制器中编写任何Linq代码,则创建依赖关系,如果站点结构发生更改,则必须进行修改,并且可能会复制数据访问代码.但是GetCustomer在模型中仍然存在GetCustomer,无论你从控制器那里调用它.那有意义吗？

比简单访问数据更广泛的业务逻辑可以放入其自己的业务逻辑层,该逻辑层被视为模型的一部分.

我对JSON不太确定.JSON只是一种替代数据表示; 如果您有一个可以将数据类转换为JSON的实用程序方法,请GetCustomer从Model 调用,并在控制器方法中执行转换为JSON.

Answer 4

该模型应处理数据访问。

从MSDN：

楷模。模型对象是应用程序的一部分，用于实现应用程序数据域的逻辑。通常，模型对象检索模型状态并将其存储在数据库中。例如，一个Product对象可能会从数据库中检索信息，对其进行操作，然后将更新的信息写回到SQL Server数据库中的Products表中。