开发背景
全世界的程序员都将减少代码量提高代码复用率作为奋斗目标。为此作出了很多努力,函数封装、面向对象、AOP、设计模式等等。这些努力极大的削减了代码的重复。但是在编程世界中我们任然存在着这样的一种代码:他们是不同的,但是他们很相似。最为典型的例子就是我们为JavaBean编写的getter和setter方法。想像一下如果没有IDE的帮助,对有100个(这不是夸张,银行系统中很常见)属性的Bean写getter和setter。那将是多么痛苦的事情。所以代码生成技术是解决此类问题的一个很好的高效的手段。但代码生成技术有自己的局限性,这是显而易见的——它只能基于某种规律来产生代码。这种规律我斗胆命名为“代码模式”。于是代码生成技术就是将需要收集的元数据(如JavaBean的属性)和代码模式融合起来经过计算生成成品代码。
元数据 + 代码模式 = 成品代码
现实世界中代码生成技术到处应用Eclipse、PowerDesigner、MyGeneration等等都获多或少的集成了代码生成技术在自己的产品中,但这些产品的共同的特点是模式过小或不利于更加智能的模式定制。比如:在一个BS构架的系统中我们要完成一个实体的CRUD功能,我们首先要定义实体属性,在定义完了所有实体的属性后,我们调用MyEclipse生成geter/sertter方法,然后我们编写DAO的接口,尽管这些DAO都非常形似。写完接口后我们写DAO的实现层。我们再次调用MyEclipse的Override/Impment Method将接口中的所有方法签名复制到实现层中来。然后再补充实现逻辑,且这些实现逻辑与其他实体也是类似的。Service层需要同样操作。在写完真个实体的功能我们需多次调用代码生成命令,且大部分代码都很类似。代码模式过小造成我们无法在人机交互界面调用一个命令来完成所有的工作。代码模式不利于定制让我们依然避免不了写相似但不同的代码。
为此公司开发了基于BS构架的代码生成器、提供可可以配置DAO\Service\Action\JSP\JS等等各层代码模式的地方。且一键可生成多层代码。
但BS构架的代码生成工具亦缺点。比较明显的是元数据的提供要求开发人员面向表设计而不是面向领域模型设计;不能将生成的代码卸载;DDL的生成基于特定数据库其他数据库不支持;无法提供像IDE一样方面的元数据录入的交互界面;生成代码后要手工调用IDE完成编译功能;支持的模式不够智能;等等。
由于各企业基本都有自己的一套技术平台、开发规范,我们可以从中抽象出具体的代码模式。然后依据此代码模式结合领域模型启动开发的思想。提供一套较为方便直观的元数据录入界面。最终完成代码生成。
实现目标
基于领域模型驱动开发的思想,提供一套较为方面直观的元数据录入人机交互界面,
提供可插拔的代码模式定制机制,完成代码生成。