给大家发一个java 自动生成Bean的工具代码

Question

john_sheep:
你发的 http://bbs.csdn.net/topics/390678591 贴子中,我已把自动生成dao代码例子发送,
由于生成dao代码太长,你以后可以自己慢慢按例子生成就行,
同时 例子的jdbc方法为java行业标准代码无需担心项目应用的问题, 当然如果楼主要求更高 可以自己再修改.

Answer 1

1 影响java性能的 基本是连接池与数据库本身的瓶颈 这种jdbc原始代码已标准化了, 只要及时在 finally 块释连接到池中,这些操作代码不用担心任何性能问题.
2 另外 批处理代码中 批量不应过大,大批量只应用在导入导出数据, 不适用在业务代码中,
 原因: 事务过大影响数据库回滚, 导致数据库性能低, 所以事务要适当.
3 jdbc 有个不足千万要注意, ResultSet rs 读取记录时 getLong 这种读取基本数据类型 返回的不是对象,而是数值, 所以如果数据库为空 返回的是 0 而不是null. 这一块要自己全部做工具处理, rs有一个 isNull判断的方法(这种是我在你的贴子中生成的代码 是用自己工具来读取的原因)

Answer 2

表关联也容易啊,写一条自己的 sql就能生成相应的Bean.

Answer 3

把查询表,改成一条自己写的sql就行.

Answer 4

把查询表,改成一条自己写的sql就行.他要的是类似hibernate的many-to-one,one-to-many之类的。

Answer 5

把查询表,改成一条自己写的sql就行.他要的是类似hibernate的many-to-one,one-to-many之类的。hibernate 从2007年开始我们就不用了, 学习可以这东西不合适用在大项目中.
many-to-one,one-to-many 要实现也不难, 问题是有这个必要么, java也用过 10多年了 还是jdbc实用.

Answer 6

通过jdbc代码 能取得表与表之前的关系, 从而可以实现他的要求.
学术研究还是可以试试.

Answer 7

关于要不要bean实现 many-to-one,one-to-many 我个人一点点看法:
1 开发语言面向对象的概念 与关系数据表之间的关系有类似的地方, 但是两者出发点不相同不能强求融合.
2 外键的概念可以用对象组合,或者对象集合的属性来描述, 但是就算这样搞出来,也与数据库的本意相差很远,
  用起来就经常说不出的感觉, 我曾经有几个月在想这个事情,最后觉得完全没有必要.
3 其实 单个对象之间的属性 本身就与数据库是一样的, 外键也是同样能体现,已经隐式实现了 many-to-one,one-to-many 这些关系, 如果再在对象里做这些东西是多余的.
4 为什么说是多余的原因我想了好久, 觉得数据库里就是这种结构bean就应当一样就够了, 之于主键,外键关系
  数据库是重定义了逻辑处理的, 我们相想: 如果不定义外键我们程序一样能处理,是不是?  
  再一个很多在项目并不是都做外键,很多都不做了,为什么? 因为程序逻辑能处理,数据库搞这个有时还不好.
  所以 bean里为什么要搞成与数据库一样呢? 只要bean有值,开发团队定义他是外键,程序照样可以处理很好: 因为有个ID,我们就能找到它的对象.
5 hibernate 是一个好的东西, 但是它并不合适生存在现实的商业项目中, 太过于理想化反而会影响灵活性.
  但是并不是他的出现没有用, hibernate 告诉我们一个道理: 可以实现自己更适合的框架.
6 经过多年的orm工具的使用 最后觉得 "最原始的工具就是最强大,最能解决问题的东西"
7 orm框架时代已过去, 现在应当回到最初的软件工程基础部分: 系统框架,系统生态,系统在应到数百个项目后的修改适应性(当然项目过多维护会死人的,这要求软件有强大的适应性)
  java众多的技术层出不穷, 但是多年来唯有spring解决的问题一直帮助着我们,其它的东西很多去不见了.8 说个故事 当公司说要做云系统,分布式服务系统, 我从java技术堆里想找个性能比较好的网络交互技术,
 webService, j2ee, rmi 性能都差强人意, 真想直接定义tcp规范 用Socket,udp,http通信,传通数据
  这段话只想说一个道理: 选择实用的技术, 最原始的就是强的工具(但不是最方便的).