多年前用ASP的时候，就听说了有一种叫做代码生成器的神奇的东西。只需要指定数据库链接，这个代码生成器就能够产生一个界面，然后选择你需要进行生成的数据表，按一下按钮，马上基于这个表的增删改查界面以及对应的ASP程序代码就生成出来，着实方便。当时的我对ASP已经轻车熟路，看了一眼这个工具后，心中评估了一下，然后使用了一把……看到这个工具生成的ASP程序源代码，让人确实有点接受不了——大小写不区分，大段大段的冗余代码。虽然生成的代码确实能够完成特定的业务操作，但是维护性确实太差了。据说后来有一些优质的代码生成器能够生成更好的程序，但是确实是从那个时候开始，代码生成器在我心里成了垃圾代码堆砌的代名词。我情愿自己编写一行一行代码也不愿意用代码生成器。

现在，当专注于某一个行业，某一种特定业务时，你会发现重复性是如此之大。——用户管理在大多数地方都是类似的，只是用户相对的字段有些不一样；用户登录界面、登出界面可能也是一样的，只是把某些图片换一下而已；大部分的业务操作都是增删改查，对于这种操作不断的采用同一种方式进行重复、还得小心出错；权限管理界面看起来也没什么大的不同……也许我们早就烦了。框架在某种程度上保证了项目的质量，但并不能减少编码量；某些框架甚至需要更多的编码（以及学习时间）。例如，与Servlet+JSP方式相比，Struts除了JSP, 还需要编写特定的Form, Action,并在struts-config.xml中加上几行；Tapestry则需要编写.page, .html, 对应的Page类，如果需要验证还得编写Delegate类；至于FreeMaker,Velocity之类界面工作量可能小了一些，但还得需要编写自己的简单框架用以实现MVC模式。Spring集成了这些表示层，看起来比较好……

上述解决方案的根本问题在于，框架只是保证了项目的质量、可维护性，但是没有减少编码量。因此，代码生成器的使用便是理所当然的了。这方面已经有先例了，最有效、最能够显示代码生成的威力的，当属xdoclet的ejb任务。我们知道，创建一个EJB需要同时创建其他四个无聊的接口，xdoclet在这方面将代码生成的威力发挥到了极致。另外，middlegen也能够创建基于数据库，使用Hibernate, Struts, EJB技术的Web应用程序，他能够生成JSP, Hibernate映射文件，Java类，EJB类等。middlegen应该是我见到的最完整的应用程序生成器的雏形，但是他还不足以具体，不足以缩短编码时间。

我思考了几天，在做OpenBUGZ和公司项目的过程中，想出了这种模型：