DDD lazy-load 是反模式?

我认为：Lazyload反模式和Aggregate加载太多是两个问题。

我在Jdonframework提供一种lazy evaluation懒赋值，区别于普通懒加载，可以想加载什么加载什么，只要你不嫌编码麻烦，比如User中有一个图片使用懒赋值：代码按这里，代码中使用事件进行二次加载，第一次触发，第二次再访问user.getUpload时，将会得到数据库中的图片。

关于Aggregate加载太多问题，DDD提出另外一种Repository查询替代模型遍历的方法。如果子对象有一万多，那无疑模型设计有问题，直觉子对象应该聚合根，而不是其父对象，父对象可能是聚合根的值对象描述而已，如产品和产品目录一样。

[该贴被banq于2013-04-17 18:56修改过]

额java中clazz写习惯了... csharp 倒是可以用@class
聚合关系只是演示, 换成别的也一样. 姑且假定我的业务就是"班级管理"而不是"班级和学生管理"吧 : -)

我想问的是, lazy-load主要是为了解决性能, 如果是它反模式, 那么替代方案是啥?

我前面提了：Lazy_evaluation：http://en.wikipedia.org/wiki/Lazy_evaluation，这其实是函数语言一个特点。

@banq 您的框架我之前下载看过, 不过一脸茫然...

demo中LazyLoader是作为Entity的父类? 那样是不是有污染Domain的嫌疑呢? 似乎用proxy更妥当.

即便是Student作为独立的Aggregate, 它还是无可避免要处理一个集合,而用Repo/app来处理集合, 感觉像是事务脚本了.

所以我觉得延迟加载是解决最佳途径,
您似乎也是赞同延迟加载的, 我不明白为什么有人认为是反模式....
另外, 延迟加载似乎还有 不一致 之类的问题, 这个怎么解呢?

UserModel是Entity，不是UserModel继承LazyLoader，为了加载其子对象Upload，可以创造一个新对象Attachment，专门为懒赋值而用，这个就可以继承LazyLoader，这实际是模板模式，不喜欢继承，可以打开lazyload的代码搬到自己代码中。

所以，模式是否反正都是相对的，某些人的观点Singleton也是反模式呢。

如果采取Spring + hibernate那种在表现层实现延迟加载OSIV倒真是反模式，见专题：OSIV: open session in view

延迟加载不能只限定在一个请求中，而是任何请求Call as need加载，这才是懒赋值和传统lazy-load的区别，如果说lazyload是反模式，也大部分因为OSIV坏了名声。

以上个人观点。