互联网分层架构的本质是数据的移动。互联网分层架构演进的核心原则：让上游更高效地获取和处理数据（多路复用），让下游屏蔽数据获取的细节（封装）。无论数据如何移动，最终都会汇聚到客户端。服务器的分层架构设计已经讲的很多了。客户端的分层架构设计应该怎么玩？在服务器的分层架构设计中有什么可以借鉴的吗？今天我就和大家简单聊聊。先从一首小诗说起：《Android猿》一旦代码全部写在Activity中，几乎没有代码可以复用。每当我在Activity中看到一个2000行的函数，我就想离开。是团队中的文艺Android程序。会员自述，表达的核心观点是：几乎所有的代码都写在Activity中（如果不了解Activity，就当它是MVC中的视图层），没有封装复用在全部。更具体的例子，在微信登录界面，点击登录按钮。这时候你可能需要执行：验证用户名和密码拉取好友列表拉取用户信息拉取好友信息拉取离线消息如果你把这些写在微信“登录活动”中，你会发现一些很严重的问题：整个登录逻辑不能复用，登录流程中的各个子逻辑不能复用，假设产品有“离线后再次登录”的功能，步骤和登录一样，需要把上面的代码复制过来在“重新登录Activity”中，同样假设产品中有一个地方需要“拉取用户信息”，那么“登录Activity”中“拉取用户信息”的代码也会被复制。封装复用的原理大家都懂，抄代码的坏处大家都懂，那为什么还有人这样做，让代码越来越“烂”？根据个人经验，主要有以下几个原因：早期业务压力大，APP属于少数学生。没有提前规划，后面的代码会越来越臃肿，不敢动。怕影响功能，怕出问题，怕承担责任。在项目中，编码是按功能接口划分的。一个同学我会同时负责MVC编码的三部分，项目压力大。既然是一个人写的，就没必要层层叠加。如果调用太多，会给项目带来麻烦。有个要求好像以前做过。看代码的时候写在Activity里，纠结。抽象成一个函数？你要改别人的代码，算了，还是抄一份吧。。。不管是历史原因，项目原因，还是个人原因，大家都知道分层抽象和代码复用是对的，那怎么解决呢？实现这种分层抽象，后端的分层架构有没有值得借鉴的地方呢？典型业务系统的后端架构如下：web-server层调用RPC接口，从service层获取数据，组装html/json，完成biz-service/data-service提供的数据展示对上游一个可重用的原子接口，实现业务逻辑，通过DAO层从db层获取数据，db层提供数据。APP端的分层架构不是很相似吗？仍以登录业务为例：(1)登录Activity有两个按钮，确认按钮和取消按钮。这两个按钮的点击只能分别调用一个函数：on_LoginConfirm_Clickon_LoginCancel_Click这里相当于表现层，除了交互和显示View层只能调用这两个函数（2）这两个函数的实现是为了验证通过几个可重用的“原子业务逻辑”函数获取用户名和密码：boolverifyPass(name,pass)拉取好友列表：ListgetFriendList(uid)拉取用户信息：UsergetUserInfo(uid)拉取好友信息：ListgetUserInfo(List)拉取离线消息：ListgetOfflineMst(uid)这个相当于服务层，实现业务逻辑，提供封装和复用(3)“原子业务逻辑”功能执行过程中，需要访问数据，数据的获取分为两种：同步获取：通过文件、内存、本地数据库获取异步获取：从服务器获取，常用这里通过回调实现的，相当于数据层，屏蔽了上游获取数据的复杂性，使用不同的Proxies来实现。在这种结构下：表现层很轻，只调用一个函数来表明数据的“原子业务逻辑”是可以重用的。不同的表现层活动可以随意组合，实现不同的业务逻辑。它们用于处理数据代理对上游屏蔽的数据采集的复杂性，向上游提供数据采集接口，用于获取数据。互联网分层架构的本质是数据迁移动态的、分层的架构封装复用思想，前后端有一个共同的地方，明知道要封装复用，为什么实现起来这么难？Activity中繁杂的代码是不是也曾是个痛点？【本文为专栏作者“58神剑”原创稿件，转载请联系原作者】点此查看该作者更多好文
