发布时间：2023-9-22 分类： 行业资讯
互联网分层架构的本质是数据的移动。
互联网分层架构演变的核心原则：使上游更高效的数据采集和处理（多路复用），使下游可以屏蔽数据采集细节（封装）。
无论数据如何移动，它最终都会聚合到客户端。服务器的分层架构设计已经被讨论了很多。如何播放客户端的分层架构设计？是否存在服务器分层架构设计的地方？让我们今天简单地与大家谈谈。
我们先来看一首小诗：
《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分层体系结构的本质是数据的移动，分层体系结构封装和重用的概念，以及常见的前端和后端。显然知道如何打包和重用，为什么实现起来如此困难？
活动中的复杂代码，是你的痛苦吗？
