中国领先的IT技术网站
|
|
创建专栏

从混乱到混乱,业务逻辑搬家记

他最早栖息在像ASP 和 JSP这样的页面当中,整天和那些负责界面展示的HTML,CSS们厮混,在这里除了展示逻辑之外,你还能看访问数据库的代码, 他们坚定不移地以制造混乱为己任,齐心协力把页面搞得一团糟。

作者:刘欣|2017-08-25 10:26

Tech Neo技术沙龙 | 11月25号,九州云/ZStack与您一起探讨云时代网络边界管理实践


1.业务逻辑同学

业务逻辑同学经常被大家戏称是业务中最不讲逻辑的东西, 这句话道出了他的本质。

这家伙不仅善变,而且特别喜欢和程序员作对,尤其喜欢制造混乱,让程序员惧怕他。

他最早栖息在像ASP 和 JSP这样的页面当中,整天和那些负责界面展示的HTML,CSS们厮混,在这里除了展示逻辑之外,你还能看访问数据库的代码, 他们坚定不移地以制造混乱为己任,齐心协力把页面搞得一团糟。

当程序员想去修改的时候就发现, 这种代码简直就是“意大利面条”, 极难阅读,极难维护。 更不用提什么代码的复用了。

每当程序员抱怨的时候, 业务逻辑说: “怪我咯? 还不是你们自己惹的祸!”

2 第一次搬家

时间久了,大家都受不了, 只好想了新的办法, 分层! 强迫业务逻辑和展示逻辑分家 !

业务逻辑被迫搬了家,再也无法和展示层的HTML,CSS一起喝酒吃肉, 每次想聊个天还必须得通过特定接口, 把数据发给展示层才行。 比如业务逻辑层会发个View Object 给展示层,把自己的孤独和思念捎带过去。 再后来展示层完全从服务器端移到了浏览器端,业务逻辑想打个招呼就得跨越网络的千山万水了。

业务逻辑退而求其次, 和Java bean 打得火热,不过很快就发现和Java bean 实在没什么好聊的,太单纯,没有一点深度,除了getter/setter方法之外,啥都没有。

有人把此时的业务逻辑称为Service , 有人称为Manager ,业务逻辑更喜欢这个名字,因为显得更加威严,更像系统的老大。

无论叫什么,其实做的事情都是一样的: 根据隔壁房间或千里之外的展示层传过来的指示, 从数据库读取数据,形成java bean(有时候连java bean 都不需要) , 进行业务逻辑运算,再给展示层发送结果。

程序员把这种Java bean 形象地称为贫血模型, 因为它一点业务逻辑都没有, 业务逻辑在Service中放着呢。

这种简单的开发方式受到了广大程序员的欢迎,它概念简单,门槛极低,初学者很快就能掌握。

建个数据库表, 创建一个对应的java 类,使用Hibernate, MyBatis把它映射到数据库表和字段上, 接下来就可以在Service 中随心所欲地操作这些Java bean 实现业务逻辑了,完全不用什么“高深的”面向对象的分析和设计 。

一个项目划分成多个模块, 大家都按照这种模式开发, 再加上一些辅助的开发工具,能够自动化从数据库表生成各种类, 实在是直接而酸爽。

一大批使用贫血模型的应用程序如雨后春笋般地出现,慢慢地变成了趋势,好像用Java做面向对象的Web开发就是这个样子。 尤其是后来维护项目的程序员, 更是觉得天经地义。

(码农翻身老刘注: 按照Martin Flower在《企业应用架构模式》中的定义,这种方式叫做事务脚本,其本质是用面向对象的语言写面向过程的程序)

这种模式对于简单的增删改查一点问题都没有,甚至还有优势 !

业务逻辑这家伙经常在诱惑程序员,来啊来啊,再多给我的Service/Manager加点逻辑。

随着系统越来越复杂, 这家伙得逞了, 大量的业务规则被添加到Service 当中,Service越来越臃肿, 开始变成巨无霸的类, 各种状态、判断、if else 交织在一起, 喜欢混乱的业务逻辑同学又激动起来, 又回到了“面条代码”的“美好”时代。

3 第二次搬家

程序员们决定再次让业务逻辑搬家, 搬到一个清静的地方去。

有一天,有个叫做Eric Evans的大神提出了一个新方案: 把Service 层和领域层分开。

(码农翻身老刘注: 在Eric Evans的领域驱动开发中,最下面是基础设施层,而不仅仅是数据访问, 我这里为了和之前的图保持一致,只把数据访问列了出来)

业务逻辑同学很不爽地发现,自己不但和展示层彻底说byebye ,还被拆分到一个个的领域对象当中去了,这些对象不仅仅是具有getter/setter的java bean , 而且拥有相关的业务逻辑、业务状态、业务规则。 现在各个领域对象要想聊天吹牛,也非得调用相应的业务接口才可以。

原来的Service 层也成功减肥,变得非常轻薄,不再包含业务规则和知识,只是为下层的领域对象协调任务,分配工作,指挥着他们完成业务任务,解决问题。

程序员们被美好的前景激励着, 努力地帮着业务逻辑再次搬家。 喜欢混乱的业务逻辑同学这次要绝望了, 以后的系统都这么搞,自己还有什么活路。

可是没想到这一次搬家难度很高, 尤其是从需求中分析合适的领域对象,实在不是一件轻松的事情,习惯了之前那种用数据库表驱动的开发方式,想转到领域模型驱动的开发方式, 让大家很不适应。

于是业务逻辑同学趁势鼓噪,算了吧,这种方法太难了,你有丰富的开发经验吗?、你有优秀的面向对象设计能力吗?你能把业务领域专家拉进来一起讨论设计吗? 不行吧? 还是退回去吧,贫血模型多好,又简单又熟悉。

这厮还真得逞了,鉴于大部分遗留系统都是贫血模型,大家没有勇气更没有时间去重构,只好将就着继续往混乱的Service舔砖加瓦,希望能熬到系统重写的那一天。

业务逻辑再次搬回到熟悉的地方,再次开始幸福的生活。

【本文为51CTO专栏作者“刘欣”的原创稿件,转载请通过作者微信公众号coderising获取授权】

戳这里,看该作者更多好文

【编辑推荐】

  1. 张有成:智能制造时代的数据安全与业务连续性保障|V课堂第74期
  2. 程序员的危机与出路
  3. 好与坏的程序员
  4. 【技术八卦第10期 】程序员们出去吃饭,回来偶遇产品经理
  5. 多对多业务,数据库水平切分架构一次搞定
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

热门职位+更多

× CTO训练营(深圳站)