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

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

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

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

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

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

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

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


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

我的代码器生成的代码 http://61.145.212.201:8080/hr/employeePersonnelBasicInformation.do

更多http://61.145.212.201:8080/hr/login.do?field(color)=CCDFE0&field(user)=ernie


双击grid可以进入明细编辑状态和操作相关子记录

所有前台和后台代码都是根据数据库自动生成，如果数据库已经建好，无需人工干预，100多个表可以在2分钟之内生成所有代码，并可以立即发布运行。

每个程序员估计曾经都有这个想法，并且也行动过，我记得以前有个同事也写了个。
但是有一点你要清楚，基本上不可能把业务逻辑通用地抽象出来。

嗯，基本上做java的都干过类似的事儿。。。。
在一定时期会有一些作用。。。
不过只在某个特定的时期内。。。
之后就是。。。
算了。。。
鼓励楼主一下，按照自己想做的事情去做吧。

CRUD在绝大多数情况下就是要和业务层面发生关系的，写代码就是应该写业务代码，和业务代码无关的尽量利用各种成熟的框架来完成，一定要说基本的CRUD么，现在单Dao设计很多的，大可参考以下。
基于楼主的做法，我认为是主要减少重复的和业务代码无关的工作，比如事务处理和ORM映射都是靠主流框架来简化工作的，代码生成只是解决了一些命名规范和楼主认为的最佳实践的内容。
我认为楼主与其精心设计代码生成，不如更好的设计自己的框架，比如BaseAction、BaseService等，应该首先通过语言的动态性和一些设计模式解决和业务不是很相关的重复劳动，而不是优先考虑代码生成。

从技术上来讲，代码生成和C++的模板编程的区别不大，属于预编译的过程，是不如语言级别上提供的动态性。我这段话讲的有点晦涩，举个例子：以前我们可以利用各种代码生成工具自上而下或自下而上的生成pojo和对应hbm配置文件，但是Hibernate3在JDK1.5提供的（动态）特性下，实现了元数据标注就不再需要这些代码生成的工具，其实对Hibernate来说它只是要知道领域和数据库的关系信息而已，以前的XML也只是存储这个关系信息的载体。
综上所诉，抛砖引玉，不要再在代码生成上花太多精力，说到底只是个预编译的过程。他所能解决的问题，用其他方式能解决得更好。

"我认为楼主与其精心设计代码生成，不如设计自己的框架，比如BaseAction、BaseService等，应该首先通过语言的动态性和一些设计模式解决和业务不是很相关的重复劳动，而不是优先考虑代码生成。"

ls说的我非常的赞成！