uc 项目总结

​      本人决定以后每完成一个项目，就做一个总结!

      iotx-uc (主要做物联网环境下, 用户设备, 场景的分享)

      由于最开始的 项目架构设计，公司这边开发主管没有和上面架构师确认过，导致接口已经开发完成，才发现存在一些问题。 最开始的数据结构中，只有 house 的概念，没有一个 group 的概念。那么，建立的数据模型，它最终只能支持家里成员之间设备和场景的分享。设备可以属于一个 house, 也完全可以属于一个 room，向上还可以属于一个小区、园区。 如果设备要在小区、园区之间建立共享的关系。现在的模型是没有办法支持未来业务的扩展的。因此，后来引入了 group 这个抽象的概念。room 可以属于某个 house， house 可以属于某个小区，小区可以属于某个街道。这样通过 group 这个概念，完全可以建立起一个层级关系，满足未来扩展的需求。

    这就体现了 建模的重要性，我们做 Java 开发无非就是把实际生产中一个需求，映射、抽象为 Java 领域的一个模型，满足实际的需求。这个模型建立的好坏，直接关系这项目的成败。我们做开发，需要提高自身一个业务抽象的能力，代码只需要懂得底层的原理，需要使用的技术、重复代码，可以从别的项目里 copy。这是没有关系的，因为这部分工作本身就是体力活，没有什么技术含量的。

    这个项目，整体感觉技术含量不是很高，但还是有一些可以借鉴的地方。

1. 接口无论需不需要入参和返回值，都可以构造为对象。这样方便后期扩展；

2. 以前接口里所有的异常情况，都是以 定义ResultCode 返回的。现在也可以这样处理，所有不满足业务的情况都抛自定义异常出去，在最外层通过 aspect 做所有接口的切面，统一进行异常和日志的处理。在这里，将异常的code转化为 ResultCode 给调用者。这样做代码感觉相对比较清晰；

3. 以前代码的 service 都是直接调用 dao 的。为了减低模块之间的耦合，便于后期的代码重构。现在可以在service 和dao 之间抽象出一个 component 或者 manager 的中间层，service 先去调 中间层，中间层再去调用 dao。这样做也可以提高代码的安全性；

4. 数据库交互方面，能够批量去做的，就不要一次次去调数据库，效率不高；

5. 代码逻辑如果比较复杂，就一个方法处理一个逻辑， 然后代码主流程 之间不同的业务代码之间，可以适当加一些空行，提高可读性；

6. 如果项目需要调用到其他的项目的服务，就单独建立一个 sal 的适配模块。在这个模块里，抓异常，封装一些业务处理的逻辑。这样做可以降低自己业务代码和其他服务之间的耦合。万一别人接口修改了，你也只需要修改这个模块。不需要动自己的业务代码；

7. 数据源的配置完全可以用配置类的形式去做，这样就少一些配置文件，代码也美观；