Backend For Frontend 实践心得

Controller

为每个页面单独写一个Controller，完全不必遵循Restful风格。

为每一个请求单独写一个方法，放弃后端接口复用。这样做有以下几点原因

• 业务上无法保证各个下拉框的取值范围一致。例如班级类型，也许在新增订单时班级类型有【普通班】和【寒假班】，但是作为查询条件时有【普通班】，【寒假班】和【暑假班】。另外作为转班时，可能下拉框有除了现在班级外其他班级，这个需要根据当前id来确定
• 权限范围不一样，如果两个页面复用了后面同一个接口，特别是下拉框这种在多个页面上复用的接口，如果不知道是从哪个页面调用过来将导致无法鉴权
• id的处理
  • 无id，这样通过url就可以查询到对应的后端方法，但是会损失信息，另外不利于下面会提到的无session鉴权。
  • id放入url中，这个是restful风格的做法
  • id放在url结尾，这个是我觉得最佳的做法。有id方便做数据权限控制。id位置固定，方便后面做方法映射。
• 下拉框中id的处理：不放入url因为这个可以做有session鉴权（也需要），另外也适应多选的情况

ViewObject

可以作为Controller的内部类，因为这个VO是专属的，其他Controller根本不可能用到。
因为vo在interface里，所以自动是public static的。
但是不同的vo的名字还是不要重复了，否则需要swagger的时候不能正确的生成文档。
另外ViewObject是class或者interface貌似都可以，反正也不用管理调用方反序列化的问题。

Implements

也不用ControllerImpl结尾，这样生成的文档更短，更简洁。

Enum

理论上api应该不用管实现的。但是这个api是专属的，只有一个实现。可以考虑使用enum，这样方便调用方（特别是通过swagger时）来准确的传入参数。

Data

列表页

物化

基本上来自Database，遵循以下原则

• schema的名字和项目名字一致
• table名字和页面的名字一致（特别是列表页）
• 列名和前端列表页的表头一致，至于筛选项是否可以不一致呢？（特别是这一列已经在表头里有的情况下）

视图

上面一种纯物化的形式当然是性能最佳的,有着以下缺点

• 双倍开发工作量,双倍代码也就意味着双倍bug
• 同步写则性能差,异步写则会在页面出现过期数据(特别是页面批量操作后更新)
• 增加字段,修改字段困难(例如日期格式),需要重新初始化数据
  基于以上问题,也许最佳实践是先写RDB,由视图来完成前期的查询工作,后期待需求稳定及性能需要优化时写一个和视图同名的表来冗余.不过这个时候作为Command写入的数据就需要写入RDB并尽可能满足各种查询要求.

详情按钮

很多时候列表页的每一行都有一个详情按钮,点击查看详情,那么要在返回列表页的数据同时将详情返回么?

返回

可能名字格式等不一致,导致前端取错数据
难以做权限控制
难以Restful风格来集成多个系统的详细数据

不返回

多一次调用,性能更差
多一个接口,开发量更大,毕竟很多时候详情页的数据是可以满足列表页的

下拉框

这种查询不复杂，可以考虑使用redis，使用hash这种数据类型

总结

无文档化