你的业务代码,是不是都写在了Activity里?

互联网分层架构演进有两条核心原则:

(1)让上游更高效的获取与处理数据(复用);

(2)让下游能屏蔽数据的获取细节(封装);

数据从数据库/缓存层,到微服务层,到站点应用层,最终都汇聚到客户端。服务端的分层架构设计已经讲了很多,客户端的分层架构设计应该怎么玩呢,服务端的分层架构设计是否有能够借鉴的地方呢,今天和大家简单聊一聊。

先来看小诗一首:

《Android猿》

曾经

    所有代码

    都被写在Activity里

几乎

    没有代码

    可以复用

每当

    看到Activity里

    2000行的函数

我就

    想要离职

上面,是团队中一个文艺Android程序员的自述,表达的核心观点是:几乎所有代码都写在了Activity里(不理解Activity的,暂且认为是MVC里的view层),完全没有封装和复用。

假设一个具体的例子,微信登录的界面,点击登录按钮,此时可能要执行:

(1)验证用户名密码;

(2)拉取好友列表;

(3)拉取用户信息;

(4)拉取好友信息;

(5)拉取离线消息;

(6)...

画外音:那个大月亮的画面,要卡很久。

如果把这些都写在微信“登录Activity”里,会发现一些很严重的问题:

(1)登录整个逻辑不能复用;

(2)登录过程中的每个子逻辑也无法复用;

 

假设产品里有一个“离线后重新登录”的功能,步骤与登录相同,就需要把上述在“重新登录Activity”里代码复制一遍。

 

又假设产品里有一个地方需要“拉取用户信息”,也将把“登录Activity”里“拉取用户信息”的代码复制一遍。

 

封装复用的道理谁都懂,拷贝代码的坏处也谁都明白,那为什么大家还这么做,代码越来越“腐烂”呢?

根据个人经验,主要是这么几点原因:

(1)早期业务压力大,APP是少数几个同学的,没有提前做规划;

(2)后期代码越来越臃肿,不敢动,一动怕影响功能,怕出问题,怕担责任;

(3)项目中,是以功能界面进行编码划分的,一个同学会同时负责MVC三部分编码,加之项目压力又大,既然是一个人写,就没必要分层了,搞多了调用反而麻烦;

(4)项目中,有个需求好像之前做过,代码一看,写在Activity里,纠结。抽象成函数?还得改别人的代码,算了,还是拷贝一份吧;

(5)…

 

不管历史原因,项目原因,个人的原因,大家都知道分层抽象,代码复用是正确的,那有什么方案能够将这个分层抽象落地,从后端的分层架构中是否有可借鉴的地方呢?

 

一个典型业务系统的后端架构如上:

(1)web-server层调用RPC接口,从service层获取数据,拼装html/json,完成数据展现;

(2)biz-service/data-service向上游提供可复用的原子接口,实现业务逻辑,并通过DAO层,从db层获取数据;

(3)db层提供数据;

 

APP端的分层架构不是非常相似么?

还是以登录业务为例:

(1)登录Activity有两个按钮,一个确认按钮,一个取消按钮,这两个按钮的点击,分别只能调用一个函数:

 - on_LoginConfirm_Click

 - on_LoginCancel_Click

这里相当于展现层,除了交互与展现,View层只能调用这两个函数。

(2)这两个函数的实现,是通过若干可复用的“原子业务逻辑”函数实现的:

 - 验证用户名密码:bool verifyPass(name, pass)

 - 拉取好友列表:List<uid>getFriendList(uid)

 - 拉取用户信息:Use rgetUserInfo(uid)

 - 拉取好友信息:List<User>getUserInfo(List<f_uid>)

 - 拉取离线消息:List<Msg>getOfflineMst(uid)

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

(3)“原子业务逻辑”函数执行的过程中,需要访问数据,数据的获取又分为两类:

 - 同步获取:通过文件,内存,本地数据库获取

 - 异步获取:从server获取,往往通过回调实现

这里相当于数据层,向上游屏蔽数据获取的复杂性,分别用不同的Proxy去实现。

 

在这种结构下:

(1)展现层非常轻,只调用一个函数,用于展现数据;

(2)“原子业务逻辑”可以复用,不同的展现层Activity可以随意组合,实现不同的业务逻辑,用于处理数据;

(3)Proxy对上游屏蔽的数据获取的复杂性,向上游提供数据获取接口,用于获取数据;

 

分层架构封装复用的思想,前后端有共通的地方。

 

Activity里一坨坨复杂的代码,也是你曾经的痛么?

推荐文章

每秒100W次的计数,架构这样设计

竞价排名真不是谁出价最高,一定排前面

数据库软件架构,到底要设计些什么

明明知道要封装和复用,为何实现起来如此的困难呢?

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值