对DAO的一些想法，附加代码(更新20091216)

更新20091216
本次更新了insert操作，请大家下载代码。

更新20091214
看到了大家的回复，非常感谢。这个框架就是一个想法，我的初衷就是先解决crud和OO，减少代码的入侵。
这次更新我完成了query的 单表查询，下次我要跟新多表查询。
代码在附件中。

在java持久层框架中有些是有状态的例如hibernate，有些是无状态的比如nutz。无论那种实现，都应该遵循一个原则，那就是面向对象。
XML做为持久层对象的配置文件，对于习惯使用java IDE的开发者来说，是不习惯的。而应annotation的反射来定义，似乎又有些对代码入侵的感觉。所以，我设计了一个框架，使用java文件本身来做配置文件。
这样的好处就是，我们可以充分利用IDE环境，减少我们的劳动量，同时，这个java配置文件有没有对其他代码入侵，所以我觉得这应该是一个好办法。

另外一个更重要的问题。为了适应多种查询，很多框架都提供了自定义sql语句接口，例如ibatis，hsql，还有annotation的注解，这些都是以字符串的形式出现的。OK，问题来了，如果我们需要对数据库进行修改，那么这些散落在不同模块中的sql语句是否可以顺利的修改完毕。对于这个问题，我的框架就容易解决了。因为我以java作为配置文件，所以在配置文件发生变化时，可以借住IDE报错，将所有涉及到的问题解决。这样我们在编译期，就把所有隐患都解决了。

希望大家看完附件中的代码，给予意见。

使用反射，是有效率问题。尤其是annotation之后，反射的使用更是大大增加。但是要看目的是什么，我觉得安全，OO，减少入侵是更重要的。

没办法 我同意lz 为了侵入性减少 效率浪费点 无所谓了也.

感觉是annotation的另一种实现。
放弃了使用语言特性，可做的并不比他多，当元数据描述的内容增加，Mapping对象将变得臃肿。
对于表字段修改，注解需要改的，Mapping对象一样需要修改。查询语句，同样是运行时检查，hibernate也有类似的对象查询接口Criteria。
至于Annotation的侵入问题，我认为既然决定使用一个ORM实现，就很少会去改变它，如果想灵活，可以使用JPA。
个人觉得应该还有很多需要改进的地方。

我怎么越看越像我写的VB代码了呢?

DataNuclues

习惯约定优于配置
有点耦合 有点侵入性可以接受
反而效率更加重要，血的教训啊

　　与框架相比，lz的做的是Java类属性与db表字段的映射，目前可以生成select语句，如果lz愿意，还可以扩展完成cud功能。不过我有几个问题：
1、如果我是调用存储过程，存储函数怎么办？
2、如果生成的sql效率不高，怎么优化（hibernate的短板之一）？
3、事务如何控制？
4、缓存呢？

　　我觉得这些都是做框架要考虑的问题。

呃。。。。

我觉得LZ做得挺好（菜鸟路过）