J2EE编写代码过程中的分包策略讨论

无论是网上还是书籍的内容，对于Java开发过程中分包的讨论不多，这个对于各个高手的程序员们似乎是个简单的事情或许说是理所当然的，所以很少人觉得这部分的内容值得分享。

我曾经的一个同事，不知道是他智商太高还是我比较弱智，他写的代码将意图隐藏地非常好，在他离职之后，他所写的代码维护起来非常困难，一些简单的内容修改都需要花费很长的时间——因为那部分的业务逻辑根本就无法定位！后来我仔细的研究了他的代码，他隐藏意图的重要的手段就是分包策略。在他的代码里，包分得很细，一个类的引用经常有5、6层的包结构，而且这些包的结构还不是按照一种的分类方法进行封装的，所以你会看到经典的三层架构下搭配业务包，业务包下分逻辑包，逻辑包下再分子业务，子业务的实现涉及到数据库又增加数据库包，另外使用了设计模式，设计模式又分了一层，这些包分下来也没上的一个数据的计算逻辑需要进行改动，还得使用DEBUG的方法一层层地往下寻找才可能找到，根本没有办法直接通过读代码就能找到相关的部分的计算逻辑。

“整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。”－－Grady Booch

如果将代码比喻为文章，那么包应该如小说的回目，能够简洁清晰地描述在这个包内的这个组合的代码的意图，例如：“甄士隐详说太虚情 贾雨村归结红楼梦”。

这几年一直从事J2EE的研发，发现现在系统的分包基本无法脱离学院派的分包方式，这种方式重要是将Control层命名为Action，Model层细分为Model包（仅保存PO类）、service包（一些业务的接口）、service.impl（业务的实现）、dao（数据库访问的逻辑实现） ，而如果业务比较负责，则会在这几个架构逻辑的分包下增加业务子包。不知道这个是从哪个例子开始的，之后的J2EE入门教科书、培训都是按照这个策略来进行分包的。

“三岁定八十”－－古语

所以在生产环境的架构的时候我们总会发现这个分包策略无处不在，虽然这个分包方法在教学的时候有助于学生对于MVC架构的理解，但是这个分包策略其实是违反了一个很重要的原则：DRY原则。

“Don't repeat yourself. Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”

当我们需要创建一个子级业务的时候，我们需要在action包、service包、dao包 下分别重复的创建子业务包。当然，如果这个系统的所有代码都是一次性的，逻辑不会继续复用，那么倒是增加了repeat了几次还算能够接受的结果。

然后最近我却遇到了问题。在我新的一个外包项目下，旧项目的一些代码和逻辑可以复用，而这些内容我只能将旧的类一个个从旧的项目中拷贝到新的项目中来，而且，由于子业务相同，所有的controller、service等的内容都需要进行拷贝，这个操作使得违反的DRY原则无限得扩大，试想一下，一些底层的服务如果出现了BUG，我必须到每个项目中寻找那个代码片段进行修改和测试！

最好的解决方法是将重用的部分代码抽取工程单独开发，通过将内容打成 jar包的形式供各个工程调用，但是分了单独工程之后，那些action、service包忽然就很碍眼了，那个违法的DRY原则也终于浮现了出来，况且如果一个包的存在开始有风险，每个工程的action、service包本来是应该只有子层逻辑的，但是抽取了工程之后，有开发人员开始将每个子逻辑的一些公用的action的内容直接放到了action包下，而如果引用的模块多，你会发现action、service包中会有一些莫名奇妙的接口出现，而不知道这些内容应该是属于那个包的（这些都是没有归宿的孩子啊）

所以考虑到以上的情况，在开发中，我们开始不再使用action之类的架构包，而直接使用业务区分策略来进行分包，再考虑接口与实现相分离的原则，新的分包策略如下：

com.xx.business1 // 所有的对外的接口（接口是泛定义，包括java中的接口、外部用的实体类等都放在跟包下，不限controller、service还是其他）com.xx.business1.entity // 存放POcom.xx.business1.impl // 可选，如果所有的实现逻辑不编写接口，那么这个包可以不存在com.xx.business1.util // 可选，一些本业务公用的操作，几乎都是静态共同的方法，当然，关于静态方法与类方法的取舍我们再写文章进行讨论

以上的分包策略在我们现在或者之后的项目都应该适用的，除非项目大到一定的程度我们再考虑结合逻辑进行分包，当然，一个业务开始很小，逐渐发展庞大之后怎么办？很简单：继续细分你的业务，而不是你的逻辑。

以上是我们新的分包策略，能够满足我们的项目需求，但是未必能够满足你的。如果有意见请留言探讨。

原创文章，转载请注明出处。http://blog.csdn.net/keijack/article/details/9083591