后端分层架构

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

移动 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 文件中。