有不少人被Spring带着跑偏了

我觉得有不少人被Spring带着跑偏了！

　　前几天我在GitHub上看到了一个在线商城的项目，star数上万，我很好奇，这个项目这么多人捧场，应该不错吧!于是把代码下载下来，浏览了一番。

　　让我惊讶的是，代码写得有点惨，长达几百行的方法比比皆是。没有面向对象编程的思维，用过程性的方式把业务逻辑统统堆砌在Service， 没有领域模型，没有职责的划分。

　　我不清楚为什么这个项目能获得这么高的star数，如果大家真的觉得这个项目质量好，那就太可怕了。我更倾向于相信很多人觉得这个项目有用，改一改就能当毕业论文，或者当简历中的项目经验吧。

　　1

　　这不是我今天想说的重点，回想起我看过的开源项目和经历过的商业项目，有个问题挺突出的：

　　这些代码中只有Controller, Service ,DAO，并且用过程性的方式把业务逻辑像垃圾一样丢到Service层当中，让Service层变得臃肿不堪，难以维护。

　　在这些代码中的领域模型被称为“贫血模型”， 特点是只有getter/setter方法，Service层经常做的事情就是：

　　1. 根据某个ID从数据库获取贫血的对象

　　2. 创建一个新的贫血对象，执行一堆业务逻辑，调用setter方法装配这些贫血的对象，然后保存到数据库中。

　　再加上修改和删除，那就是的CRUD了。

　　贫血的领域模型在这里主要承担的是数据容器和数据传输的职责，而不是计算业务逻辑的地方。

　　关于贫血模型，充血模型， 15年前在javaeye网站上就有过非常充分的讨论(参见文末的链接)，没看过的强烈建议读一读。

　　软件开发大牛Martin Fowler在18年前也出版过一本书，叫做《企业应用架构模式》，其中讲到的“事务脚本”就是这种方法。

　　没想到这么多年过去了，还是有很多Spring项目在使用事务脚本/贫血模型!

　　当然，没有东西的，事务脚本/贫血模型也有它适用的地方，那就是对于简单的，没有复杂业务的系统，大部分都是CRUD， 那可以地把系统给搞起来。

　　但是业务逻辑一旦变复杂，Service层就难以承受，变得难以阅读，难以修改，难以维护了。 这时候一定要做出重构，给Service层减负，让业务逻辑呆在它应该呆的地方，即领域模型当中。

　　2

　　我在标题中说被Spring带着跑偏了，好像是把锅甩给了Spring，冤枉Spring了，管人家Spring什么事?明明是程序员没有用好嘛!

　　在网上有一种说法：Spring的作者Rod Johnson也承认，Spring也是在沿袭EJB2时代的“事务脚本”，也就是面向过程编程 !

　　虽然我没有找到这句话的原始出处，但是不得不说SSH/SSM对很多初学者的误导作用，在SSH/SSM的很多例子当中，用的都是这种贫血模型，这就给初学者带来了一种印象：把贫血的领域对象当作C语言的结构体，把Service当作C语言中的函数来使用，似乎这就是正确的用法。

　　Martin Fowler提出了贫血模型这一反模式以后，Spring的核心开发人员Craig Walls(也是《Spring实战》的作者)在2005年就写过一篇文章《Spring 2.0 vs 贫血模型》，其中阐述了Spring 2.0如何避免贫血模型，不过他在其中提到的是领域模型自己处理持久化，然后需要引用DAO的问题。

　　3

　　很多人给我说工作琐碎，修修补补，很没意思。我建议看一看自己的项目，是不是符合这样的条件：业务复杂+贫血模型，如果是的话就可以学习面向对象的设计，体会一下真正的领域模型。

　　如果你成功了，看到清爽的、薄薄的Service层，有着充分测试用例的Domain Object，心里会很爽的。

　　从执行策略上来说，先要想办法获取支持，如果没有首肯，自己私下里练习一下，然后把漂亮的结果展示给看看，更有说服力。

　　如果你面对这样的代码束手无策的时候，不妨看看这篇文章：《当15年的老司机遇到烂项目、烂代码时，他会做这5件事!》

　　我知道做出这样的改变是不容易的，但是这么做了才是体现你能力的时候，是让你脱颖而出的时候。