为什么需要提供更多构建 POJO 的手段

当查询以及获取一个或者是多个 POJO 时，Nutz.Dao 采用反射来创建对象以及为对象的各个相关字段填充值。为了提高速度，Nutz.Dao 对对象采取一些缓存的策略，所以基本上不用去查询每个对象的构造函数以及getter，setter 或者公共字段,所有的时间开销都集中在反射的 invoke 方法上。事实证明，这让 POJO 的构建速度提高了不少，但是对于那些还想对速度进行优化的应用，怎么办呢？ Nutz.Dao 还提供了更加极限的手段。

将构建的过程掌握在你自己的手里

有些人说JDK1.5 以后，反射更快了。并且由于 Nutz.Dao 对于实体的反射做了缓存，所以它创建对象比一般的反射更快，但是，还是有些人不满意，他们还需要更快。优先顺序：

public Pet(ResultSet rs){}
public static create(ResultSet rs){} // 工厂方法的名称可随意定
public Pet(){} // 这是最常用的方式,会通过FastClass进行加速.
public static create(){}

以上形式的方法必须有一个,如果均不存在,会抛出异常,提醒添加无参构造方法.

总结一下这四个约定

通过头两个约定，你可以让你的数据库操作同直接调用 JDBC 接口一样快。别忘了，在数据库操作的时候，拼装SQL 这点小开销几乎可以忽略不计。第三个约定，适用于在你不希望暴露POJO的构造函数的前提下。最后一个约定则是 Nutz.Dao 的默认期望的工作方式。

本页面的文字允许在知识共享署名-相同方式共享 3.0协议和GNU自由文档许可证下修改和再使用。

原文: http://nutzam.com/core/dao/pojo.html