浅谈客户端架构

客户端有哪些架构？

MVC(简略)

M层为数据层，两个用途：1保存数据；2发送数据更新信息；

V层为视图层，两个用途：1接受用户从界面上的操作；2根据M层的数据显示相应的界面；

C层为控制层，两个用途：1处理和界面无关的代码逻辑；2接受和处理网络数据；

MVP

很多时候视图层面还是充斥中很多复杂的逻辑，例如UI事件的响应处理，网络响应的回调等等，充斥着各种监听器的回调。我们期望视图V便当更简单、更纯粹，V只负责绘制和刷新其他逻辑都不用管了，也不想和M有直接的联系。从MVC的VC（Activity）中我们分离一层出来叫做Presenter，由它来负责调度UI何时刷新、由它来接受UI的事件响应并传达指令给M。从此V和M是路人，V和数据的距离跟远了.

V：Activity为代表，这时候的Activity更为简单了，只负责UI的绘制和刷新。

P：负责传达指令。向上接收V的事件指令并需要的时候传达给M，向下接收M的指令并通知V刷新UI。

M：只负责出来数据逻辑。

我们把每一层都抽象成一个接口，例如V层，我们定义一个接口为View（不要和AndroidAPI里的View弄混了），让后Activity为这个View的具体实现。每一层对另一层的依赖都是接口依赖，并不关心另一层的具体实现，每一层我们都可以写不同的实现，随时切换，这就意味着，有一天如果有一层不好用了，我们可以轻松的重写另一个实现来替换掉，而不是如履薄冰的修改

如何评估架构？

层次可扩展性

也称纵向扩展设计。该设计工作是为了分解复杂的问题域和抽象问题对象，采用分层技术，适当对系统规划多个层次部份，然后最终再整合起来构成一个完整系统整体。

评价的时候可以考虑系统是否需要进行分层？分层方案是否适合？层与层之间的整合方案是否适合且有效？

架构