问题
1. “你的业务逻辑层为什么要按照数据库的表来建立。一旦数据库的表更改了岂不是业务逻辑层也要更改么。”当大师傅问我这个问题的时候,我才反应过来我的业务逻辑层理解的有问题,当时我是把业务逻辑都放到了U层,导致U层很累赘。
2.当沾沾自喜以为给U层解负担的时候,惊奇的发现,B层还是被架空了。(这个问题是出于B层依然是按照数据库表来建立的。)
所以,我才重新开始反思 ,业务逻辑层的到底是应该怎么建立,为什么第一次发现这个问题了,还出现业务逻辑层架空的问题。
原因分析
什么是业务逻辑层?
- 业务是指一个实体单元向另一个实体单元提供的服务。
- 逻辑是指根据已有的信息推出合理的结论的规律。
在网上搜索了很多的资料,找了一个解释的蛮有意思的。业务逻辑是指一个实体单元为了向另一个实体单元提供服务,应该具备的规则与流程。就像你家的规矩–“吃饭前必须洗手”“有客人来要起立”“睡觉前各自说晚安”-就是业务逻辑的生活化实例。
业务逻辑的内容包括四个部分:
- 领域实体:定义了业务中的对象,对象有属性和行为;
- 业务规则:定义了需要完成一个动作,必须满足的条件;
- 数据完整性:某些数据不可少;
- 工作流:定义了领域实体之间的交互关系。
下面是假设引用的“
以大毛网购裤子”为例
的一个例子:
- 领域实体:大毛、资金账户、订单、裤子、发货单
- 业务规则:大毛点击购买就会生成订单,但必须付了钱,才会发货,生成发货单。
- 数据完整性:淘宝网下订单必须登录账号,没有账号就不能成功购买。
- 工作流:搜索裤子-找到合意裤子-下单购买-付账-收货。
所以,在大毛网购裤子这一业务逻辑:搜索“裤子”-找到合意裤子-下单-必须登录账号-结算-付账-收货。
业务逻辑层里到底应该是什么?
笔者在问了很多大神的博客或者论坛里找到了一个比较好的说法:
根据上图的解释,我们首先要明确这些业务逻辑的多种关联动作是在B层内部进行的。那么问题就来了,到底怎么内部进行,进行的这些动作到底是什么,方法么,还是类么还是什么其他的?简单的说通过什么方式才能让这多种关联在形成一个完整的流程。这个问题我们后面再说。其次,“即使是不会变成的人也可以设计业务逻辑”。在机房合作期间,由于之前的重构(未完待续)