背景

随着项目的扩大，我们需要更好的架构来组织整个项目的代码和逻辑，以便于提供项目的可维护性，可读性。

MVC

在没有前后端分离的时候，MVC（Model–view–controller）是我们最常见的一种架构。把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。

• 模型（Model） 用于封装与业务逻辑相关的数据获取以及对数据的处理方法。简而言之就是从数据库中获取数据
• 视图（View）用于实现数据显示。例如呈现某个HTML文件的模板、以JSON的形式返回内容
• 控制器（Controller）用于控制请求的流程。常见的模式就是从模型中获取数据，并指定视图返回

MRSC

目前，大多数 Client-Server 模式的应用程序都是采用了前后端分离。后端只需要提供 API 给前端即可。前后端通讯的数据形式基本上都是 JSON 格式，至于前端如何根据后端提供的数据来实现视图层的呈现，这个已经不是后端开发所需要关心的，所以视图层没了，剩下 Model 和Controller 层。

针对这种前后端分离的开发模式，在MC层之间中加入了 Repository 和 Service 层级。

题外话：其实MVC 也可以加入 Repository 和 Service 层，他只是一种架构的理念。

我相信你没听说过『MRSC』，因为这个是我创造的名词，这个架构不是我创造的，而是我作为一个简单总结。

MRSC分为模型（Model），仓库（Repository），服务（Service），控制器（Controller），职责简述如下：

模型（Model）

负责对表字段，常量，表映射等的定义。过去我们把很多业务逻辑和数据操作的实现都放在了Model，但不再建议这么做，而是把这些逻辑挪到 Repository

仓库（Repository）

作为数据层，它负责实现对模型的数据的操作（增删查改）。

Repository 中定义的方法名，应该是用来描述数据是以怎样的形式去维护的。比如 searchUsersByPage、searchUsersById 和 insertUser。

Repository 只绑定一个 Model，只允许维护与当前 Repository 绑定的 Model 数据，最多允许维护与绑定的 Model 存在关联关系的 Model。比如，订单 OrderRepository 中会涉及到的订单商品 OrderGoodsRepository 的数据。

服务（Service）

负责特定领域的具体业务实现。

Service 中定义的方法名，应该是用来描述功能或业务的（动词+业务描述）。比如handleListPageDisplay 和 handleProfilePageDisplay，分别对应用户列表展示和用户详情页展示的需求。

调用 Repository 处理数据

控制器（Controller）

负责校验权限和请求参数合法等

调用 Service ，让Service 实现具体的业务逻辑

该架构的调度流程如下Controller <=> Service <=> Repository <=> Model，需要遵循上述的调用层级，以下操作是不建议的：Controller 中调用 Repository、Model ，Service 中调用 Model。