设计 Service 的一些经验
1. 接口粒度设计
Dao 接口应该 raw 一点，更贴近 DB，细粒度一点（接受参数列表），参数多一点。
Service 接口应该是 “应用定制型”，粗粒度一点（比如接受对象参数），参数少一点。
如：CouponDao.getCoupon() 我们可以传一个 status 参数；但是 CouponService.getCoupon() 就没必要用 status 参数了，线上没有拿 STATUS_USED 券的应用场合，调用 CouponDao.getCoupon() 时直接把 status = STATUS_AVAIL 写死就可以
2. 大原则：不要自己空想！
从 Controller 和前端接口文档入手，Controller 需要啥就写啥！
3. 拆分 Service
不知道把方法放到哪个 Service 或是不知道该不该新建一个 Service 时，直接把新方法写到最大的 Service 里，等接口多了，再来拆分 Service。
拆分 Service 的原则：
- 返回类型一致的方法可以放到同一个 Service 里；
- 使用同一套 dao 的方法可以放到同一个 Service 里；
- 现实本体（程序是对现实世界的模拟，那么方法、类都是模拟了现实世界的一部分，这个部分我们成为现实本体）明显是同类的方法可以放到同一个 Service 里，比如
BasketBallService的timeout、substitution、dnp方法就应该 extract 到CoachService
Comments