业务层其实并不复杂，但是大部分开发人员对其职责并没有理解清楚，从而使其沦落为一个数据中转站。
　　业务层的职责
　　所以，设计业务层之前，对业务层的职责要先真正理解清楚。这里，小优举两个栗子说明一下。
　　个是新用户注册的例子。注册时，界面上一般都会要求用户输入手机号、验证码、密码和确认密码。但是，API接口一般只会有三个参数：手机号、验证码和密码，不会有确认密码。因此，调用接口之前，密码和确认密码的一致性检查是必须的。同时，也要检查这些数据是否为空、手机号是否符合规范、验证码是否有效、密码有没有包含了特殊字符等。正确姿势就是当所有检查都通过了之后，才调用API接口。后，调用注册接口成功后，可能还要再调用一次登录接口，并可能将用户登录信息缓存起来，方便用户下次启动应用时自动登录。所有这些都属于业务逻辑处理，也就是业务层的工作。
　　第二个是涉及用户验证的例子。比如，在一个电商App，当用户浏览某个商品，点击购买时，App首先会判断用户是否已经登录，如未登录，则会跳转到登录页面让用户先登录。如果已经登录，但token已经过期，那需要先去获取新的token，之后才能进行下一步的购物操作。这些逻辑处理，也是业务层的工作。
　　因此，简单点说，业务层就是处理业务逻辑，包括数据的检查、业务分支的处理等。比如上面第二个例子，可能很多人就会将用户是否已经登录的判断直接在界面上做处理，当确认登录后，token也是有效的之后，才调用业务层做购买商品的操作，这就是导致业务层沦落为API的数据中转站的直接表现。
　　业务层的交互
　　只有真正理解了业务层的职责之后，才能有效地设计业务层与外层的交互接口。
　　业务层向下，与数据层交互;向上，与展示层交互。
　　与数据层交互只是调用数据层的接口获取数据，而与展示层交互则需要提供接口给展示层调用。因为业务处理一般属于比较耗时的操作，主要在于底层的网络请求比较耗时，所以提供给展示层的接口数据结果应该以异步的方式提供，因此，接口上就需要提供个回调参数，返回业务处理之后的结果。
　　业务层可以说是一个数据加工场，处理核心的业务逻辑。其实，只要理解清楚了业务层的职责，业务层就不难实现。

責(zé)任編輯：優(yōu)網(wǎng)科技

版權(quán)所有：http://www.jcoyc.com (優(yōu)網(wǎng)科技) 轉(zhuǎn)載請(qǐng)注明出處