面向对象的困扰

在当今这个ORM的时代，我们的Domain Object不经意间变成了一个个Data Object，EJB3的EntityBean尤为如此。

曾经尝试过在EntityBean中加入其CRUD及业务方法，让它看起来好像是一个Domain Object。DAO没有了（这个东东更像是面向过程，我们这里抛开Design Pattern），直接在SessionBean中操作EntityBean来完成Business。

问题来了，EntityBean由容器负责persistence，通过Annotation无法给EntityBean注入EntityManager，需要从SessionBean获取再交给它，这样会直接导致这个所谓的Domain Object不能串行化，这样的Domain Object还有意义吗？

另外，这个臃肿的EntityBean也违背了其设计者的初衷，究竟是面向对象限制了EJB，还是EJB天生不适合面向对象？

目前Java的框架还不能够很好的实现你想要的Rich Domain Model模型。

除非使用AspectJ对domain进行拦截，注入DAO，或者使用Hibernate的Interceptor进行拦截注入DAO，这样才能让Domain对象rich起来，目前EJB3的EntityBean是没有这个能力的。

现有的框架，真正良好的支持rich domain model的其实是ruby on rails。

dawnzhang 写道：



要面向对象，就不要使用EJB，或者其他Remote Method Invocation 技术。
使用普通的JAVA类，就是最大化的面向对象。
分布式编程总有很多限制。

确实目前的 Object 持久方案基本都是将 Data Object 真的当作 "数据" 去看待和实现, 这本身已经脱离了 OO 将 "行为" 加之于 "状态" 而进行整体封装的思想主线. 而业务逻辑也就只是通过对 "数据对象" 的操作去实现了, 这还是老一套的思维模式. 或者说是 "贫血的模型".

有空不妨看看 TOB http://www.iteye.com/subject/TheObjectBase, 基于这个新的数据库, 你就可以直接在应用持久模型里实现业务逻辑了. http://wow.dev.java.net 是个很好的参考项目.

从用例到领域对象再到关系数据持久化，complystill让我们似乎看到了EJB梦想照进现实的那一天
面向大内存的架构设计还期待我们去体验，正在路上...

OO永远是被动的，必须靠if,else来推动，因此，OO并不能解决问题的全部


被赋予了信息之后，OO才能有用武之地，但很多系统只是对信息本身的操作，只需要第一步就能满足需求，因此OO刃之锋锐就被雪藏了。

   非常同意你的看法！我们做的很多系统都只是CRUD，这种过程式的语言也很容易满足要求了（如PHP），并不需要过多地提OO，目前来看贫血模式（这个概念很吓人，哪个流氓提的啊 ）还是比较适合的，也比较成熟。我想我们没有必要为了OO而去OO，快速解决问题才是关键，并不是每个一个Object都一定要数据＋方法，这样也不免有点学究了。

严重赞同！！

牺牲一下  让domain object 知道spring的context,自己找到一些基本的crudDao,这样感觉好很多。。。