互联网分层架构的本质是数据的移动。

互联网分层架构演变的核心原则：使上游更高效的数据采集和处理（多路复用），使下游可以屏蔽数据采集细节（封装）。

无论数据如何移动，它最终都会聚合到客户端。服务器的分层架构设计已经被讨论了很多。如何播放客户端的分层架构设计？是否存在服务器分层架构设计的地方？让我们今天简单地与大家谈谈。

我们先来看一首小诗：

《Android猿》

一次

所有代码

写在活动

几乎

没有代码

可以重复使用

每当

请参阅活动

2000行功能

我会

想要离开

以上是团队中文学Android程序员的自我报告。表达的核心是：几乎所有代码都是在Activity中编写的（暂不理解Activity，暂时是MVC中的视图层），没有封装和重用。 。

更具体的例子，微信登录界面，点击登录按钮，你可能想要执行这个时间：

验证用户名和密码

拉朋友列表

拉用户信息

拉朋友信息

拉离线消息

如果你在微信中写这些“登录Activity”，你会发现一些非常严重的问题：

登录到整个逻辑不能重复使用

登录过程中的每个子逻辑都无法重用

假设产品中有一个“重新登录然后重新登录”的功能，步骤与登录相同，您需要在“重新登录活动”中复制上述代码。

还假设产品中有一个地方需要提取用户信息“rdquo;并将复制“获取用户信息”中的“登录活动”代码。

每个人都知道包装重复使用的原则。每个人都理解复制代码的缺点。那么为什么你仍然这样做，让代码变得越来越“腐烂”，根据个人经验，主要有几个原因：p>

早期的业务压力，APP是几个学生，没有提前计划

迟到的代码变得越来越臃肿，不敢动，害怕影响功能，担心问题，害怕责任

在项目中，函数接口用于编码和除法。一位同学也负责MVC三部分代码。此外，项目压力很大。由于它是由一个人编写的，因此无需对其进行分层。拨打更多电话很麻烦。

在项目中，有一个似乎已经完成的需求，代码看着它，写在Activity中，纠结。抽象成功能？你必须改变其他人的代码，忘记它或复制它。

…

无论历史原因，项目原因，个人原因，每个人都知道分层抽象，代码重用是正确的，那么有什么计划能够抽象这个分层，是否有一个地方可以从后端分层架构中学习什么？

典型业务系统的后端架构如下：

Web服务器层调用RPC接口，从服务层获取数据，组装html/json，并完成数据表示

Biz-service/data-service提供了一个可重用的上游原子接口来实现业务逻辑，该层通过DAO层从db层获取数据。

db层提供数据

APP端的分层架构不是很相似吗？或者以登录服务为例：

（1）登录Activity有两个按钮，一个确认按钮，一个取消按钮，点击这两个按钮只能调用一个功能：

on_LoginConfirm_Click

on_LoginCancel_Click

这相当于表示层。除了交互和表示之外，View层只能调用这两个函数

（2）这两个函数的实现由许多可重用的“原子业务逻辑”函数实现

验证用户名和密码：bool verifyPass（name，pass）

拉好友列表：ListgetFriendList（uid）

拉用户信息：使用rgetUserInfo（uid）

拉朋友信息：ListgetUserInfo（List）

拉离线消息：ListgetOfflineMst（uid）

这相当于服务层，实现业务逻辑，提供封装和重用

（3）“原子业务逻辑”在功能执行过程中，需要访问数据，数据采集分为两类：

同步采集：通过文件，内存，本地数据库获取

异步提取：通常通过回调从服务器获取

这相当于数据层，屏蔽了上游数据采集的复杂性，使用不同的Proxy实现

在这种结构下：

表示层非常轻，只调用一个函数来显示数据

“原子业务逻辑”可以重复使用，不同的表示层活动可以随意组合，实现不同的业务逻辑处理数据

代理向上游屏蔽数据采集的复杂性，为上游提供数据采集接口以获取数据

Internet分层体系结构的本质是数据的移动，分层体系结构封装和重用的概念，以及常见的前端和后端。显然知道如何打包和重用，为什么实现起来如此困难？

活动中的复杂代码，是你的痛苦吗？