Android分层架构笔记

第1部分：核心原则

• 让上游更高效的获取与处理数据（复用）。
• 让下游能屏蔽数据的获取细节（封装）。

服务端的分层架构思想就是以此为原则进行封闭的，服务端屏蔽数据的获取，只管提供给客服端具体的数据，客户端同样不了解数据具体的获取方法，只管请求需要的数据即可。

第2部分：Android中的问题示例

• 遇到有的项目把所有的逻辑都写到了Activity中，代码几千行，封装性很差，维护性更差。
• 具体示例：获取验证码的逻辑，登陆需要有一个、注册也需要有一个、可能某块逻辑又增加一个验证手机号，同样的逻辑需要写好几个地方，十分的不方便维护。

第3部分：造成该结果的原因

• 早期业务压力大，APP是少数几个同学的，没有提前做规划
• 后期代码越来越臃肿，不敢动，一动怕影响功能，怕出问题，怕担责任
• 项目中，是以功能界面进行编码划分的，一个同学会同时负责MVC三部分编码，加之项目压力又大，既然是一个人写，就没必要分层了，搞多了调用反而麻烦
• 项目中，有个需求好像之前做过，代码一看，写在Activity里，纠结。抽象成函数？还得改别人的代码，算了，还是拷贝一份吧

第4部分：根据服务端分层架构思想设计客户端分层架构

1.服务端

• 结构：web-server —-> biz-service —-> db
• 说明：
  
  • web-server层调用RPC接口，从service层获取数据，拼装html/json，完成数据展现
  • biz-service/data-service向上游提供可复用的原子接口，实现业务逻辑，并层通过DAO层，从db层获取数据
  • db层提供数据

2.客户端

以用户登陆功能来说：

View层：LoginActivity

• 上面有两个按钮，一个登陆，另一个是取消登陆。

Control层：

• onLoginConfirmClick
  
  • bool vertifyPass(name, pass)
  • User getUserInfo(uid)
• onLoginCancel

Model层（负责数据获取）：

同步获取：

• LocalDbProxy 数据库获取
• LocalFileProxy 文件获取
• LocalMemProxy 内存获取

异步获取：

• ServerProxy 网络获取

第5部分：总结

在这种结构下：

• 展现层会非常轻，只调用一个函数，用于展现数据。
• “原子业务逻辑”可以复用，不同的展现层Activity可以随意组合，实现不同的业务逻辑，用于处理数据
• Proxy对上游屏蔽的数据获取的复杂性，向上游提供数据获取接口，用于获取数据