最近开发了一套代码生成工具。

好久没更新日志了，我最近花了大概一个多月的时间做了个代码生成工具，生成的代码都是和公司的框架相关的，生成相应的后台代码和前台代码和配置文件，目前可以通过数据表和po来生成相应的代码，那么可以生成单表，树型单表，主从表，树型主从表这几种模式。当然它生成的只是这个项目里面最常用的操作，比如新增，修改，删除，导出等等。那么生成的逻辑都是最简单的逻辑，开发人员可以在生成后的基础上，将具体的逻辑判断加进去。生成的界面就是列表页面，新增页面，修改页面，查看页面。当然如果是主从表，那么就会生成从表的维护页面，那么前台页面的基本验证都可以生成好了，比如日期，是否为空，是否是数字等等。


我个人感觉它有以下三个作用。
1.可以提高一定的工作效率，因为可以生成60%-80%的代码，而且有IO处理，是可以直接生成到你指定好的工作目录里面去。开发人员之用将生成的配置文件拷贝到相应的目录即可，那么开发人员可以把更多的精力投入在复杂业务逻辑和技术攻关里面。
2.可以让项目做的更统一，因为生成的后台代码和前台代码是统一的，界面也是统一的，那么项目就是统一的风格，不会出现这个人的界面是一样，其他人又是另一样。
3.可以节约单元测试，系统测试的成本，不用局限于测一些共性，简单的功能。

但是这个生成工具是以一个稳定的开发框架和一套界面标准为基础的。

在下一版本，我将做以下修改。
1.增加xml数据源和json数据源（目前是数据表 或者po）
2.将框架的模板，代码和 业务数据分开。（这是个大的工作量），这样可以适应各个不同的开发框架。
3.加上预览的功能，主要是预览界面的布局。
4.加上高级布局功能，让布局更加灵活。

希望大家对我这个生成工具多多提些建议，我想3月初就在公司里投入使用。

评论

35 楼 seele 2008-03-05  

和你怎么说不明白呢？在一个复杂的企业应用里面，是极少有纯的CRUD代码的。你在添加一个User的时候，难道不用去校验其用户名是否已经重复，就直接save进数据库了？对于每个表，CRUD的逻辑都不一样，你的代码生成有甚么意义？

基础代码的含义是针对框架的简单封装，具体的业务逻辑开发需要的则是大量的业务分析和单元测试，这恰恰都是一个软件和核心，迷信甚么代码生成的，我敢说，写出来的代码多数都是无法满足严格的单元测试的。


引用这个大哥写的话,CRUD是对单对象最基本的操作,而你说的校验的,就是属于业务层面了...把职责分配给合适的对象来操作,才是面向对象的精髓

34 楼 CnXiaowei 2008-03-05  

我也是为了方便，自己开发了一套代码生成工具生成基本的代码，而且可以根据不同需要设定模版，这样无论直接的JDBC还是用了ORM工具例如Hibernate，都可以简单的生成。
后来又看到生成的代码中重复性质的还是比较多，因此又自己开发了一套简单的数据层的东西。
我觉得代码生成多少可以节省一些coding的时间，而且没有最好的东西，只有合适的东西，只要东西用着方便，能节约时间，就是好东西。

33 楼 isky 2008-03-05  

你好  你如果用的JPA 或者 Hibernate  entityManager  我想请问你一个 问你
你在Dao方法中 能有验证属性唯一性的方法嘛？
拿来分享以下  以为我做个好多次  都失败了 因为有hibernate的缓存机制 导致我屡次失败  我用过hibenate的 监听器  和  缓存清除  都不行 ！
   静候佳音！

32 楼 isky 2008-03-05  

应该拿来分享以下嘛  。。。。。

31 楼 eivenchan 2008-03-05  

期待楼主开源...
我最近也在做类似的东西..
不过我选择的不是代码生成...而是源数据...
例如,在CRUD的展示中,配置每个字段的展示方式,展示格式,输入格式,是否为空等...
而且还加入了逻辑配置,例如在新增一个User的时候,配置他的username不同与当前数据库已有的username重复...

但是由于个人经验太浅,所以感觉到了瓶颈,不知道如何做了...

30 楼 惊鸿逝水 2008-03-05  

downpour 写道

惊鸿逝水 写道

不管是不是ORM，就算是简单的DAO也可以用一条语句实现，但是面对类似的几十个的CRUD(只是表名不一样)，用代码生成器选择多个表，1秒钟就帮你批量生成所谓的重复代码，总比手写有效率吧！

和你怎么说不明白呢？在一个复杂的企业应用里面，是极少有纯的CRUD代码的。你在添加一个User的时候，难道不用去校验其用户名是否已经重复，就直接save进数据库了？对于每个表，CRUD的逻辑都不一样，你的代码生成有甚么意义？

基础代码的含义是针对框架的简单封装，具体的业务逻辑开发需要的则是大量的业务分析和单元测试，这恰恰都是一个软件和核心，迷信甚么代码生成的，我敢说，写出来的代码多数都是无法满足严格的单元测试的。

你又真的明白我的意思？
赫赫，难道你添加一个User我就不能帮你生成校验代码？当你诸如这样的操作有NN个的时候，你不觉得很琐碎吗？
谁告诉你用代码生成器就可以帮你实现完整的应用呀？我只说可以帮你生成可运行的系统雏形，具体实现逻辑根据需求做修改！

单元测试和用不用代码生成器没关系！代码生成器的作用我上面说过了，不再重复。

29 楼 downpour 2008-03-05  

惊鸿逝水 写道

不管是不是ORM，就算是简单的DAO也可以用一条语句实现，但是面对类似的几十个的CRUD(只是表名不一样)，用代码生成器选择多个表，1秒钟就帮你批量生成所谓的重复代码，总比手写有效率吧！

和你怎么说不明白呢？在一个复杂的企业应用里面，是极少有纯的CRUD代码的。你在添加一个User的时候，难道不用去校验其用户名是否已经重复，就直接save进数据库了？对于每个表，CRUD的逻辑都不一样，你的代码生成有甚么意义？

基础代码的含义是针对框架的简单封装，具体的业务逻辑开发需要的则是大量的业务分析和单元测试，这恰恰都是一个软件和核心，迷信甚么代码生成的，我敢说，写出来的代码多数都是无法满足严格的单元测试的。

28 楼 惊鸿逝水 2008-03-05  

abcx 写道

对于CRUD，还需要用代码生成器来生成吗，ORM框架完全可以完成。另外，我们开发的是富有人性化的逻辑严密的应用程序，而不是面向数据库的CRUD（不光Java代码面向数据库，UI也面向数据库）。谈到框架的维护问题，采用优秀成熟的框架，至少还有一个社区在维护这个框架，至少在你的应用程序被淘汰之前，你不用太担心框架被淘汰。

不管是不是ORM，就算是简单的DAO也可以用一条语句实现，但是面对类似的几十个的CRUD(只是表名不一样)，用代码生成器选择多个表，1秒钟就帮你批量生成所谓的重复代码，总比手写有效率吧！

至于你说的富有人性化的严密逻辑,这不是什么生成器能够实现的。但不可否认，管理系统的大部分功能都是所谓的“重复”,写上10遍CRUD，做上十几个翻页的功能页面我也会觉得烦！

框架要不要采用最先进，还是最优秀的，“只买对的，不买贵的”用你最了解，最熟悉的框架吧，就算是已经淘汰的框架也有它的用武之地！另外，开源的框架最严重的问题就是兼容性，谁也不会轻易去升级一个稳定的框架(比如struts1.x 到struts2.x)！

27 楼 jeamzhang 2008-03-05  

其实我觉得LZ说的有点矛盾，你不是说你们公司是用的自己的框架吗？那有这么能做成产品啊，不会把你们公司的框架也做进来吧。那样的话，就需要先看看你们的框架在看你的代码生成工具了。前段时间也自己给自己做了几个代码生成的类。比较简单：是使用Hibernate生产好的值对象来生成各种java类(差：web界面生成这块)。
我觉得：代码生成工具都是比较片面的。想做成个产品太难了。每个项目都有不同的界面要求。
如果大家有需要我的代码生成类。我到可以共享。但是是C#的。嘿嘿，最近搞C#。但是编码方式都是差不多的。少量修改可就可以用了。

26 楼 abcx 2008-03-05  

惊鸿逝水 写道

abcx 写道

抛出异常的爱 写道

abcx 写道

如果你在架构设计和编程方面不是很牛，请不要尝试做这样的事，更多的时候你做出来的是垃圾。

牛这个词是贬义.....
能够节约劳动...就是好东西..
垃圾大多是由于懒人不去改进.....

首先代码生成器的存在是因为有大量重复冗余的代码存在，这就是一个设计上的问题了，应该从设计入手，同时选择高效的框架和技术，自然就可以消除冗余代码，剩下的代码都是业务逻辑代码，业务逻辑代码是用代码生成器就可以生成的吗？
还有一个严重的问题就是维护问题，谁来理解和升级你的框架，还有那一大堆你的框架生成的代码，需求变了，这些代码该怎么变？

不是完全同意，需要代码生成器的地方可能有：
1)系统每个模块可能都需要相同的处理逻辑功能，比如CURD操作，生成模板化的展示页面
2)为了简化开发的工作量，生成模板化的代码，只要添加少量的逻辑实现，就形成可运行的系统雏形
3)为了统一项目的包命名规范、类命名规划、代码结构，形成一致的编码风格

可以说，再优秀的框架和技术，一旦工作量上来了，在人员参差不齐的情况下，代码生成器还是非常便捷的。
对于需求的变更，通常是属于业务层次的，我想既然是一个架构平台，又岂能不剥离业务？

另外，说到框架的维护问题，不管你是采用自己的，还是开源的都是需要面对这个问题，无可逃避！

对于CRUD，还需要用代码生成器来生成吗，ORM框架完全可以完成。另外，我们开发的是富有人性化的逻辑严密的应用程序，而不是面向数据库的CRUD（不光Java代码面向数据库，UI也面向数据库）。谈到框架的维护问题，采用优秀成熟的框架，至少还有一个社区在维护这个框架，至少在你的应用程序被淘汰之前，你不用太担心框架被淘汰。

25 楼 rockjava 2008-03-05  

抛出异常的爱 写道

abcx 写道

如果你在架构设计和编程方面不是很牛，请不要尝试做这样的事，更多的时候你做出来的是垃圾。

牛这个词是贬义.....
能够节约劳动...就是好东西..
垃圾大多是由于懒人不去改进.....

行万里路，始与足下。懒人终究会失败的。

24 楼 fang9159 2008-03-04  

大家好，我是楼主，看到大家这么多的留言，心情是非常激动，我现在会逐步来对你们进行回复。

23 楼 抛出异常的爱 2008-03-04  

重构系统是要钱与时间的.
大部分公司是不会给你时间与金钱的.

22 楼 惊鸿逝水 2008-03-04  

abcx 写道

抛出异常的爱 写道

abcx 写道

如果你在架构设计和编程方面不是很牛，请不要尝试做这样的事，更多的时候你做出来的是垃圾。

牛这个词是贬义.....
能够节约劳动...就是好东西..
垃圾大多是由于懒人不去改进.....

首先代码生成器的存在是因为有大量重复冗余的代码存在，这就是一个设计上的问题了，应该从设计入手，同时选择高效的框架和技术，自然就可以消除冗余代码，剩下的代码都是业务逻辑代码，业务逻辑代码是用代码生成器就可以生成的吗？
还有一个严重的问题就是维护问题，谁来理解和升级你的框架，还有那一大堆你的框架生成的代码，需求变了，这些代码该怎么变？

不是完全同意，需要代码生成器的地方可能有：
1)系统每个模块可能都需要相同的处理逻辑功能，比如CURD操作，生成模板化的展示页面
2)为了简化开发的工作量，生成模板化的代码，只要添加少量的逻辑实现，就形成可运行的系统雏形
3)为了统一项目的包命名规范、类命名规划、代码结构，形成一致的编码风格

可以说，再优秀的框架和技术，一旦工作量上来了，在人员参差不齐的情况下，代码生成器还是非常便捷的。
对于需求的变更，通常是属于业务层次的，我想既然是一个架构平台，又岂能不剥离业务？

另外，说到框架的维护问题，不管你是采用自己的，还是开源的都是需要面对这个问题，无可逃避！

21 楼 抛出异常的爱 2008-03-04  

abcx 写道

抛出异常的爱 写道

abcx 写道

如果你在架构设计和编程方面不是很牛，请不要尝试做这样的事，更多的时候你做出来的是垃圾。

牛这个词是贬义.....
能够节约劳动...就是好东西..
垃圾大多是由于懒人不去改进.....

首先代码生成器的存在是因为有大量重复冗余的代码存在，这就是一个设计上的问题了，应该从设计入手，同时选择高效的框架和技术，自然就可以消除冗余代码，剩下的代码都是业务逻辑代码，业务逻辑代码是用代码生成器就可以生成的吗？
还有一个严重的问题就是维护问题，谁来理解和升级你的框架，还有那一大堆你的框架生成的代码，需求变了，这些代码该怎么变？

先把手里的活干了再说别的.

20 楼 neora 2008-03-04  

抛出异常的爱 写道

abcx 写道

如果你在架构设计和编程方面不是很牛，请不要尝试做这样的事，更多的时候你做出来的是垃圾。

牛这个词是贬义.....
能够节约劳动...就是好东西..
垃圾大多是由于懒人不去改进.....

严重同意。

19 楼 abcx 2008-03-04  

抛出异常的爱 写道

abcx 写道

如果你在架构设计和编程方面不是很牛，请不要尝试做这样的事，更多的时候你做出来的是垃圾。

牛这个词是贬义.....
能够节约劳动...就是好东西..
垃圾大多是由于懒人不去改进.....

首先代码生成器的存在是因为有大量重复冗余的代码存在，这就是一个设计上的问题了，应该从设计入手，同时选择高效的框架和技术，自然就可以消除冗余代码，剩下的代码都是业务逻辑代码，业务逻辑代码是用代码生成器就可以生成的吗？
还有一个严重的问题就是维护问题，谁来理解和升级你的框架，还有那一大堆你的框架生成的代码，需求变了，这些代码该怎么变？

18 楼 jomper 2008-03-04  

ls说的很中肯

17 楼 daquan198163 2008-03-04  

关于你说的三个作用：
1.可以提高一定的工作效率，因为可以生成60%-80%的代码，而且有IO处理，是可以直接生成到你指定好的工作目录里面去。开发人员之用将生成的配置文件拷贝到相应的目录即可，那么开发人员可以把更多的精力投入在复杂业务逻辑和技术攻关里面。
2.可以让项目做的更统一，因为生成的后台代码和前台代码是统一的，界面也是统一的，那么项目就是统一的风格，不会出现这个人的界面是一样，其他人又是另一样。
3.可以节约单元测试，系统测试的成本，不用局限于测一些共性，简单的功能。
=============================================================
1、我认为通过代码生成来提高工作效率很有限，因为磊代码只占整个开发工作量的很小一部分，
而且根据你的说法，应该是在一开始的时候一次性的生成一些基础代码，其实完全可以用项目模板来做这件事。
2、同上
3、能生成的只是少数，大量的新开发业务逻辑还是需要单元测试

16 楼 Godlikeme 2008-03-04  

期待lz的例子早点拿出来，证实一些想法和说法吧。