# 后端分层架构

下图是移动 PaaS 平台的后端代码分层示意图：

采用贫血模型分层架构。对外（前端、平台外部）以 RESTful 风格提供 API。API 定义遵从这样的规则：

• 按操作的资源划分，资源名使用英文单词的复数形式。
• 一般情况 Controller 中的方法名与路由名称一致。特别情况下名称不一致需要理由说明。
• 参数中多个 ID 使用英文逗号分隔。

RESTful API 定义示例：

方法	路径	Controller对应方法名	备注
GET	/accounts	AccountController.index	列表
POST	/accounts	AccountController.store	新增
GET	/accounts/{id}	AccountController.show	查询
PUT	/accounts/{id}	AccountController.update	更新
DELETE	/accounts/{id}	AccountController.destroy	删除
PUT	/accounts/{id}/changepw	AccountController.changepw	改密码,id可以省略（如果是修改当前用户的密码）
GET	/subaccounts/{id}/ekpname	SubaccountController.ekpname	得到子账号的ekpname

# Controller 层

• 按操作的资源划分 Controller。以用例拆分方法。
• 命名：资源名英文单数(首字母大写)+Controller，如 WebappController
• Controller 中的代码遵从的规则和职责：
  • 客户端提交数据的基本合法性校验，不包括业务校验。
  • 调用下层 Service 完成一个用例。
  • 不能调用 Model 层对象。
  • 依赖注入对应的 Service。

# Servcie 层

Service 层内划分了2个小层级。靠下的一个层级与数据模型（表）一一对应，封装了对这单个数据模型的模型操作（图示中的 XServcie 和 YService）。他遵从这样的规则：

• 与数据表一一对应
• 命名：数据表名 + Service
• 实现与单表相关的业务逻辑。没有特别的单表业务逻辑时，这个类可以不创建。
• 不可以调用其他 Service
• 只能调用与他同名的 Model。（去除 Service 和 Model 后缀的名称相同）
• 不能出现拼接 SQL 的代码。

靠上这个层级是封装了跨数据模型的业务逻辑操作（图示中的 SceneService）。他遵从这样的规则：

• 按业务场景、需求故事划分 Service。
• 命名：业务名英文单数 + Service。

• 可以调用下层各个 Model 和 其他 数据模型Servcie
• 不能出现拼接 SQL 的代码。

# Model 层

• 对数据模型（表）一一对应。
• 命名：表名单数（首字母大写） + Model。
• 只做 CURD。
• 无数据库事务。（事务在 Service 层管理）
• 无业务逻辑。
• 对于数据库的连表操作，sql写入主表的 model 文件中。