使用springdoclet简化基于spring框架的应用开发
FuqiangWang
2014年从msn space存档中重新恢复出来！
楔子
之前写过几个基于spring的程序，因为规模不是很大，所以，开发过程中并没有探索更有效的开发流程，仅仅是手工编辑spring-config.xml文件，虽然通过个人的细心与努力最终能够成功的完成这些程序，但是，开发过程中也难免的暴露一些问题，在无意间看到springdoclet的时候，萌生了我想写下这篇文字的念头…
在说springdoclet带来的便利之前，我还是先说说之前的开发流程，这样也好有一个比较。
在没有任何途径得知基于spring框架开发流程是一个什么样的情况下，我开始了我的第一个spring-based应用的编写，在穿梭于源代码和配置文件之间多时之后，我最终形成了类似风格：将配置文件先扔一边，直接编写应用类，如果该类依赖于其他类，那我声明他们，然后IDE直接生成相应的setter,getter方法，当所有应用类完成之后，从主入口类开始，依次添加到spring-config.xml配置文件中，因为类似于从上倒下的索引形式，通常也不会遗漏任何类，所以也可以很顺利的配置下来，加上SpringIDE的支持，这种方式也可以很好的完成我的工作。
不过，我前面说过，这个流程也存在一定的问题和不便：
首先，因为是最后一次性将类配置完成，而即使程序规模不大，那类的数量通常也不会太少，起码10几个二十几个应该有吧，加上属性等，那你在最终配置的过程中就需要尤其谨慎，因为这么些信息的组织稍有不慎就可能出错（所以，后期我有时候直接是写一个应用类就直接配置到spirng-config.xml中）；
其次，虽然Eclipse等类似的IDE现在对于重构支持已经很不错，但是，他们也仅仅是对源代码级的重构支持很好而已，对于其他的相关配置等却基本没有支持，而你又不可能保证你的所有类配置到spring-config就一次通过运行（有这样的可能，不过很少），所以你需要时不时的调试并修改相应的源码，这个时候，源代码的变动势必造成配置文件的相应修改，没有了重构的支持，可想而知，遗忘或者稍有大意，错误就会更愿意频频光顾你了。
当然，说这些不是说以上流程就一无是处，而是为了找出可以解决这些问题和不便的方法，所以，下面我们来看看springdoclet是如何帮助我们避免以上的纠缠的。
我不想对springdoclet做详细的介绍，他只属于xdoclet为spring开发提供的一个task，想知道有关的更多信息，可以参考后面罗列的几个参考项，我这里只想说一下使用springdoclet后的开发流程以及与原来相比有什么便利：
使用springdoclet，我们现在就可以完全撇开手工配置spring-config.xml配置文件这一过程，而全身心的投入到应用的开发过程中。现在，我们只需要关注应用类的编写就可以了，也就是说，现在的开发流程其实也就是上面提到的流程的前半部分，唯一的差别就是，现在，我们在完成一个类之后，要相应使用springdoclet的Tag为其标注相应标志和依赖。虽然就这个差别，实际上可以随着项目规模的增长，为开发带来的更大的便利。
现在你只要关注单一的一个文件—java源代码，再也不用穿梭于源文件和配置文件，管理一个类和管理多个类加上配置文件相比，无论是工作量还是出错几率，都大大降低了；
而且，随着项目规模的增长，为了增进开发人员的协作，我们通常会将spring-config.xml按照功能或者层次等分成多个来使得开发人员的开发可以并行进行，虽然如此，依然会存在多个开发人员需要注册同一个配置文件的情况，而使用了springdoclet之后，每个开发人员只需要关注自己开发的相关应用类并标注他们就可以了，完全不可能出现多个开发人员在一点出现冲突的情况；
对于调试过程中的重构来说，因为你现在只关注源代码文件，所以，随着你对代码 的更改，对于就在眼前的javadoc，我想你不会视而不见吧？！只需要更改相应的javadoc，再也不用再跑到配置文件中搜寻相应配置并手工更改了。
补充说明 好像光说原来流程的不足以及光说基于springdoclet流程的长出有些不公平，所以，我还是再补充一下，以免有失偏颇。
其实，原来的流程也不是一无是处，既然是手工编辑，那么你就可以拥有最大的灵活性，你可以根据需要添加属性，可以像在java中应用DesignPattern那样在xml配置文件中引用类似配置结构，这些在某种程度上提高了配置文件的可读性及可维护性，而使用springdoclet，你通常就做不到这些，因为模板是写死的，他只能照章办事，呵呵，跟“制度是死的，人是活的”一个道理，虽然你可以自定义template，不过，你也会相应的付出一定的代价；
另外，springdoclet也不是对所有的spring.dtd中的结构都提供了很好的支持，就像后面要提到的，某些结构还是需要你自己来添加相应的支持；
还有就是springdoclet也不会为我们生成所有需要的配置，某些情况下，需要我们自己手动维护某些文件，虽然可能通过某些方面的努力来让他为我们生成所有的，不过，在付出的代价和取得的成果之间，最好有一个权衡。
其他的就不再赘述了，随着开发的进行，我想更多的感受会自动过来找你的。
TroubleShooting
- springdoclet对于某些property注入默认不提供支持，这种情况下怎么办？！
- 类似问题可以参照后面的参考资料部分第二项《扩展XDoclet对Spring List引用注入的支持》，xdoclet框架有很好的可扩展性，你可以按照自己的需要来对其进行扩展。对于《扩展XDoclet对Spring List引用注入的支持》这篇文章来说，我觉得文中提到的对原发布包进行更改的方式欠妥，实际上，完全可以通过自定义模板或者添加merge point来实现相同的功能，对原发布包也没有侵入性，以后要share的话，也仅仅只需要share模板就可以，第三方可以通过任何途径取得xdoclet的发布。
- springdoclet只能根据源代码中的tag生成相应的配置文件，但是，对于不属于当前项目的类，如何将其集成到generate过程中？！
- 其实，我想说的是，对于当前项目的源代码，你可以通过添加相应的tag来实现类的注入，springdoclet也可以根据这些tag为你生成相应的配置文件，但是，对于第三方类库来说，你无法对其源码进行任何操作（实际上，大部分都是class形式发布），这个时候，我们如何让springdoclet在生成配置文件的时候将这些类一起merge到最终的输出中那？！
- 我觉得这个问题本身已经不能放到code generation这个范畴，springdoclet也不能为我们做这个事情，实际上，完全可以单独设置一个配置文件，按照需要声明这些依赖类，而源码中可以通过tag标注这些依赖类的引用，最后，结合这个配置文件和最终生成的配置文件就可以了。
GOOD LUCK!
参考资料
- Manning《XDoclet In Action》by Craig Walls ,Norman Richards(建议读一下，里面对于Code Generation和XDoclet的一些理念对于开发和设计理念很有帮助，即使没有时间，起码读一下第一，第二，第12，13章，或者后面相应的appendix) 2.《扩展XDoclet对Spring List引用注入的支持 》from http://www.crackj2ee.com/Article/ShowArticle.asp?ArticleID=557 3.XDoclet documentation from http://xdoclet.sourceforge.net/
「福强私学」来一个？
「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。
开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。
