开发设计心得(关于“架构”设计)

96
justCode_
2017.07.22 16:51* 字数 1288

最近这段时间一直在赶项目,作为程序员,不加个班,好像都不太像。(唉,累)不过,还好,任务分解得还行,同事也给力,每天就工作9小时左右吧,也勉勉强强的可以和进度匹配。

项目开始前期,做基础框架(有人也叫基础架构)。就是封装好一些网络请求,数据模型,通信策略之类的吧。花了差不多两天时间,但是,老大一句话“这个框架写得不好,回调太多,我希望是链式调用”,,,,好吧,一个字“改”。其实,说起框架或者架构,很多初学者会想到mvp,mvc什么的。会想到,这个我们用mvp吧,,,但是,个人,对mvp或者mvc不太推崇。个人,比较什么喜欢模块化,和分层化。分层,主要分业务层和ui层。模块化是按业务分模块。

先来聊聊这个分层思想吧,这是看了计算机网络5层结构后,想到的。其实,一个app,也可以类似的分层,用户看到的UI层,后台的业务层。这个就和别人说的前后端分离,其实是一个思想,就是把前台页面和后台逻辑分开。这里,就要提出一个分离思想。当然,这里的前台页面,可不只是说写xml这些哦,其中包含了页面效果,比如,转场效果,动画想过,流畅度,适配,页面反馈等等。而后台逻辑,其实,是包含了网络请求,数据模型,数据处理,异步任务,多线程等等。通常的小项目,就按照这种方式去分层,基本都是ok的,不过,涉及到一些物联网之类的,可就要再加一层了,这一层,我称之为协议层或者叫通道层,其实就是tcp、蓝牙、无线传输协议那一类的。如果,项目再复杂一点,那我就大致分为以下几层:

第一层,ui层,这个不需多说,app都必须,也最为重要,毕竟用户才不管你逻辑。

第二层,逻辑层(业务层)主要是对ui层提供对应业务接口或者数据访问接口

第三层 ,数据模型层,这一层是对网络请求或者tcp,或者蓝牙,或者其他的资源来源的接收和处理层。对逻辑层提供原始数据(当然,编解码之类的肯定在这层完成了)

第四场,我觉得叫外连层吧(这个名字没想好,所以项目中就叫commom了),这一层主要是,访问网络,连接tcp,连接蓝牙,调用三方库之类的吧。

差不多吧,我觉得一般项目,这4层,基本是够了。不过,这样分层有一个弊端,就是对开发人员的框架思想要求比较高,对接口的使用和定义要求比较高。简单来说,就是适用人群,就剔除了那些新人朋友吧。这套设计的关键,其实就是设计api或者sdk,除了ui层,其他三层,几乎都要设计成sdk级的才能发挥这套设计的最大威力。举个例子,UI层,想要获取用户信息,那么UI层,只需要调用如getUserInfo(userID)这个方法,ok,就可以拿到这个数据了,而不需要理会是网络获取,还是本地数据库获取什么的。

再来聊聊模块化这个话题,模块化网上搜说的话,一大堆。这套设计,主要是为了,匹配,公司人员之间技术层次不统一开发的,把业务模块详细划分,分配到指定人员,每个人只负责开发自己那个模块,与其他模块分离。就不需要每个人都对业务很了解,每个人都只需要了解自己那一亩三分地。而且,这种设计,在小项目中,非常适用。最近一个项目,就是用的这种方式,两个人开发了一个类似与cartogo的app,花了两周。

今天,这些东西,就是自己的一些开发心得和设计心得吧。不过和其他大神相比,那就是相形见绌了。毕竟,小菜鸟一枚。

后续,再分享,在开发中的一些细节,和踩过的一些坑。

日记本