看了很多外文贴和文章, 一些人说lazy-load是反模式, 理由是: 如果一个Aggregate需要加载太多数量的元素, 那这个模型就是有问题的. 但同时几乎没人给出一个合理的解决方案.
比如说一个Clazz聚合, 包含一个List<Student> students, 而后者的数量可能超过1万, 每个Student又包含更多其他Entity. 业务逻辑多数情况下不需要对 students进行操作( 比如修改Clazz的名称之类的)
如果对students的操作是只读, 那么CQRS应该可以解决, 但Clazz可能需要批量修改每一个学生的信息.
这类模型应该如何设计?
首先你拼写错误，不是叫clazz，而是叫class吧
另外，为什么class要聚合student。student完全就是独立聚合根才对。
我认为：Lazyload反模式和Aggregate加载太多是两个问题。
我在Jdonframework提供一种lazy evaluation懒赋值，区别于普通懒加载，可以想加载什么加载什么，只要你不嫌编码麻烦，比如User中有一个图片使用懒赋值：代码按这里，代码中使用事件进行二次加载，第一次触发，第二次再访问user.getUpload时，将会得到数据库中的图片。
关于Aggregate加载太多问题，DDD提出另外一种Repository查询替代模型遍历的方法。如果子对象有一万多，那无疑模型设计有问题，直觉子对象应该聚合根，而不是其父对象，父对象可能是聚合根的值对象描述而已，如产品和产品目录一样。
[该贴被banq于2013-04-17 18:56修改过]
我前面提了：Lazy_evaluation：http://en.wikipedia.org/wiki/Lazy_evaluation，这其实是函数语言一个特点。
UserModel是Entity，不是UserModel继承LazyLoader，为了加载其子对象Upload，可以创造一个新对象Attachment，专门为懒赋值而用，这个就可以继承LazyLoader，这实际是模板模式，不喜欢继承，可以打开lazyload的代码搬到自己代码中。
所以，模式是否反正都是相对的，某些人的观点Singleton也是反模式呢。
如果采取Spring + hibernate那种在表现层实现延迟加载OSIV倒真是反模式，见专题：OSIV: open session in view
延迟加载不能只限定在一个请求中，而是任何请求Call as need加载，这才是懒赋值和传统lazy-load的区别，如果说lazyload是反模式，也大部分因为OSIV坏了名声。
以上个人观点。