？？？？？？？？？？？？？？

文章已删除

看不明白你说的东西。你说Dao不应该存在了，但是根本没给出一个解决方案，哪怕是一个没有任何可行性的方案。我不能从你的代码中看到任何有新意的东西。
难道你认为把myThings = somethingDao.getThingsOf(me);变成List<Something> myThings  = person.getThings();就可以消灭Dao了？
滑稽。
这两种读取方法虽然有些不一样，但是你这么写的前提是至少还有一个PersonDao。先读取用户，然后用Hibernate自动加载属性对象功能读取Something列表。这有什么新意？如果你只有Something的id呢？你最后还不是需要一个SomethingDao？
Dao不是这么消灭的。无论如何，也会有这么一个封装持久化操作的对象存在。也许日后会用AOP的方式让程序员看不见，不用自己写。但是你不能说它不存在。

这个例子是想说明，如果用Hibernate这类的持久层框架来实现DAO，DAO是无法起到其本来的作用的。当通过PersonDAO取得一个Person对象后完全没有必要再通过SomethingDao取得Something了。

解决方案就是JPA（Hibernate），将持久化工作交由EntityManager或HibernateSession去完成。

确实，上面代码确实没有什么“新意”，因为我想用这几行代码来说明DAO是无意义的（在JPA的语境下）。

关于JPA（Hibernate）的案例，可以看看JBPM的实现，我觉得很有启发性。另外，它还展现了真正的OO设计，而非POJO这类Object-Relationship的过渡产物。

PS：这个帖子其实是我在另外一个讨论中的回复（关于使用Hibernate时是否有必要DAO），然后我把它发到我的博客上了。没有把上下文交待清楚，不好意思。

其实我们现在所说的Dao基本上指的就是持久层，Dao可以说是持久层的代名词。即使现在写持久层和最初的纯JDBC完全不一样了，习惯上也叫Dao。如果你觉得现在持久层叫Dao不合适，那么可以改个名字。上来直接说Dao无意义了，那么大家就认为你的意思是要把业务和持久化混在一起。

而且我也说过，如何从持久层取数据，有很多种情况。你是因为框架自带属性对象加载功能，所以可以不调用somethingDao。但是你却不能把personDao去掉。而且如果你的业务本身和person无关，只有something相关的。那么你仍然不能避免somethingDao的存在。无论它是否叫这个名字，总有这么一个东西。

我们都理解对方的意思了

DAO只是封装底层的sql语句！提供连接数据库的接口。
如果你不用DAO，那把hql语句或者sql摆到哪里？

不知道你说的琐事是什么
在标准的EJB开发中只有JPA没有Hibernate...那这样琐事谁来干

使用DAO，意义在于可以让业务逻辑层专注业务逻辑，不用关心持久化操作，其次是实现持久层的可插接性。
JPA只不过是把几种持久化框架封装了一下，根本不能替代DAO。难道你想在业务逻辑里填满EQL？

我会使用NamedQuery，即使有DAO，我也不愿意看到Java Code里混入QL。

Hibernate是一个JPA实现，也可以用其他厂商的实现，不过我只用过Hibernate。

我正打算写一个简单的xml实现，有兴趣大家可以一起探讨。
不过我猜可能已经有这样的实现了，哪位知道有关的信息，请告诉我一下哦，谢谢。