机房重构时候,用到了外观,但是在用外观的时候基本上业务逻辑层没有在体现出它本身的功能,而是将
业务逻辑基本转移到了外观层中,也没想太多直接就那么敲完了重构;不过在合作的时候我们达成了一致,让
外观发挥外观的功能,B层发挥业务逻辑的功能,在此之前需要弄清楚以下两个概念:
一、什么是外观?
在设计模式中我们学习过外观模式,都知道外观是为子系统中的一组接口提供一个一致的界面,很多人也
见过下面的图片
这张图生动形象的表明了外观的作用,可以为U层提供很清楚的接口,非常方便
但是我们在具体做机房的时候会无意识的把外观的作用曲解,我们先接着往下看
二、业务逻辑层(B层)
什么是业务逻辑?业务逻辑是对数据业务逻辑的处理;乍一听是对业务的逻辑,但具体是什么呢?
业务逻辑的内容包括一下几方面:
1.领域实体:业务中的对象,包括属性和行为;
2.业务规则:规定完成一个动作需要满足的条件;
3.数据完整性:一些必不可少的数据;
4.工作流:实体之间的交互关系;
看起来还是很模糊的概念,不太明白,举个例子说,就那机房登录来说吧
1.领域实体:用户名,密码
2.业务规则:点击登录会登陆系统,但必须在用户名和密码都输入正确的情况下才能登录进入系统
3.数据完整性:用户登录需要有登录的用户名和密码,没有则不能登入系统
4.工作流:输入正确帐号密码—>点击登录—>提示成功—>进入系统
这才算是业务逻辑层,而我们写的业务逻辑层是什么?只是返回一个值,完全被我们架空了
三、转移
重构的时候我们外观似乎是发挥了业务逻辑层的作用,数据完整性,业务规则体现的淋淋尽致,还有不可
或缺的工作流,现在已经意识到这个问题的存在,接下来就是要解决这个问题,转移,让他们各自发挥自己
的责任
外观:是对B层一些类进行汇集,为U层提供一个清除的界面,让U层和B层更好的解耦
B层:把本该属于B层的业务逻辑从外观拿回来,充分发挥B层的作用
敬请期待下一篇关于具体解决业务逻辑转移的问题
小结:团队合作中大家会有很多不一致的想法,当我们在表达自己的观点或是在听别人的观点的时候是一个
很好的学习的过程,通过我们思想的交流和碰撞,对知识的理解更加深刻