互联网分层架构的演进有两个核心原则：使上游能够更高效地获取和处理数据（多路复用）；使下游能够屏蔽数据获取的细节（封装）；并将数据从数据库/缓存层传输到微服务层，再到站点应用层，最后汇聚到客户端。服务器的分层架构设计已经讲的很多了。客户端的分层架构设计应该怎么玩？在服务器的分层架构设计中有什么可以借鉴的吗？今天我就和大家简单聊聊。先说一首小诗：《Android猿》所有的代码都写在Activity里，几乎没有代码可以复用。每当我在Activity中看到2000行的函数，我就想离开。是团队里的文艺Android程序。会员自述，表达的核心观点是：几乎所有的代码都写在Activity中（如果不了解Activity，就当它是MVC中的视图层），没有封装复用在全部。假设一个具体的例子，在微信登录界面点击登录按钮，可能需要执行：验证用户名和密码；拉取好友列表；拉取用户信息；拉取好友信息；拉取离线消息；……画外音：大月亮的画面久久不能定格。如果你把这些都写在微信的“登录Activity”中，你会发现一些很严重的问题：整个登录逻辑无法复用；登录流程中的各个子逻辑不能重复使用；假设在产品”功能中有一个“离线后再次登录”的功能，步骤和登录一样，需要在“重新登录Activity”中复制上面的代码。另外假设在需要“拉取用户信息”的产品，“登录活动”中“拉取用户信息”的代码也会被复制。封装复用的原理大家都明白，抄代码的坏处大家都明白，那为什么还有人这么做，而且代码越来越“烂”？根据个人经验，主要原因有以下几点：(1)前期业务压力大，app为少数学生所有，没有提前做规划；（2）后期代码越来越臃肿，不敢动，怕影响功能，怕出问题，怕承担责任；(3)在项目中，是以功能接口来划分Coding。一位同学将同时负责MVC编码的三部分。此外，该项目面临着巨大的压力。既然是一个人写的，就没必要层层叠加。打电话太多会很麻烦；(4)在项目中，有个需求好像以前做过。看了代码，写在Activity里，纠结。把它抽象成一个函数？你要改别人的代码，算了，还是copy吧；(5)...不管是历史原因，还是项目原因，还是个人原因，大家都知道分层抽象和代码复用是正确的，那么有没有什么方案可以实现这种分层抽象呢？后端分层架构有参考吗？一个典型的业务系统的后端架构是这样的：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)拉取用户信息：使用rgetUserInfo(uid)拉取好友信息：ListgetUserInfo(List)拉取离线消息：ListgetOfflineMst(uid)这个相当于服务层，实现业务逻辑，提供封装和复用（3）“原子业务逻辑”功能执行过程中，需要数据accessed，获取数据分为两类：同步获取：通过文件、内存、本地数据库获取异步获取：从服务器获取，往往通过回调实现。这相当于数据层，阻塞了上游数据获取的复杂度，分别用不同的Proxy实现。这种结构下：(1)表现层很轻，只调用一个函数来展示数据；(2)“原子业务逻辑”可以复用，不同的表现层活动可以随意组合，实现不同的业务逻辑，用于处理数据；(3)Proxy为上游屏蔽了数据采集的复杂性，向上游提供数据采集接口；分层架构封装了多路复用的思想，前后端有共同点。Activity中乱七八糟的复杂代码是不是也曾是一种痛？【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
