领域模型的超延迟加载初步设计

hibernate老早就支持！...

呵呵 是啊。。。但是我总觉得那个东西用起来晕得要死，不如直接写HQL。

这种方式还是没有 HQL，SQL等查询语言那样直观和易维护。
//等价script：(name = 'tom' and isMale ) or name = 'Beth'.   这种更好一些。

到领域模型这里，我觉得以下方式好一些：

child.setName("Tom");
child.setSex("1");

map.put("otherName","Alice");
liy.getChildren().query("name = :name && sex = :sex  or name = :otherName",child,map  );

query(exampleObject);  //QBE
query(queryString, exampleObject); //query string + QBE
query(queryString, exampleObject,otherParamMap); //query string + QB + other param
queryByName( namedSqlName); // named query

这三个接口也是我设计的查询的四个接口，没有其他。 简单的用前两种， 复杂的用 named sql query。Hibernate,Ibatis 都是支持的。

Criteria我不太喜欢采用。

taowen 同学，你的作品正在拜读。 初看很不错，读完了再交流，呵呵。我也在做这样的小研究。

svn拉下来，
看到好多模板和接口，一头雾水，那位同学看懂了解说一下哈

DetachedCriteria直接使用貌似没有什么价值的。但对于上百个表，上千个字段（假设平均每个表10个），之间关联关系复杂的，而用户需求又多变的。无论在重构和代码的管理上都比HQL要好很多。写HQL也好，SQL也好，DetachedCriteria也好，都需要去查entity的对象关系图，因为太多字段，太多entity了。现在基本是用PowerDesigner管理这些表，然后再用工具生成DAO，这些DAO带有一种"script"的性质，带有一个生成的、辅助的DetachedCriteria操作对象，利用JAVA IDE的"."自动显现对象方法的功能，可以使得开发人员不必老是去查各种表的关系，无论是对于开发、团队合作、后期维护、较复杂的重构，都能节省不少工作量。在实际的应用中确实是一种节省成本的做法，最简单的一个例子，entity发生改变，几乎所有需要修改的文件都会出现红色的"x"，因为编译错误，而HQL的错误，你只有用测试和代码搜索的功能来定位了，而且漏改的可能性很高。
   从代码书写的灵活性来说，动态语言的无疑会比静态语言高很多，像RUBY这样进化很快的动态语言尤其如此，但对于一个不断变化的需求的现实世界，如何更好的管理散漫到各个地方的代码进行有效管理呢？我个人觉得静态语言仍然有其优势的。不过当哪一天IDE的发展可能会弥合这种差别，现在JAVA这样的静态语言的"动态扩展"可能会是一个发展方向。