昨天用一天的时间重复制造了一个轮子，又一个OR mapping。
又一个使用annotation的orm的实现，非常无聊的东西。 不过实现过程中，思考了一下，感觉从select出发的orm往往是非常难用的。再简单的系统，其select语句也会出现复杂的内外连接，分组等查询逻辑。 但是在数据存储部分，也就是upate ,insert,delete部分，逻辑往往是非常简单的，使用orm会得到比较好的效果。 然后，要反思一下DAO模式，在通常理解的DAO模式中，数据的读取和写入是放在同一个DAO类当中的，在实际开发中，select相关的findXXX方法好getXXXX方法非常多，但是update,insert,add,save等方法个数都比较少，个人认为开发DAO或者说数据访问层程序的时候，应该讲DAO分为写入DAO和读取DAO，同时可以考虑在此实现读写分离，写入一个库，读取多个库，读加缓冲池，写直接写入，利用数据库机制表同步，以提高系统的伸缩性。 而且根据@1哥的答案，写入操作本身就是一个非常慢的动作，在写入时加入反射，犹如大象身上的虱子，相对磁盘来说，反射的消耗应该可以忽略。 然后，顺便对于NutzDAO进行一下小小的批评，作为DAO中间件，有些事情做了太多，反而不太好，比如引入所谓的whereClause的条件查询，真实业务中的select的SQL非常复杂，用简单的条件封装，很难满足真实开发需要的。 要知道hibernate一开始也很好用