Table of contents
背景
随着项目的扩大，我们需要更好的架构来组织整个项目的代码和逻辑，以便于提供项目的可维护性，可读性。
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。