传说是这样的，对象其实真实的实体存在于两个地方，一个是DB，一个是Repository的地方。
但是访问这些对象的“人”，有两个目的，一个是只是看一看，就好像是没钱的男人进入迪吧(DB)一样，只能是看一看，因为他们也只是花看一看的钱，这时候，系统会通过Repository给Reader的人一个看似和真正Entity对象一样的对象，但是这个对象不是正在“操作中”的实际活的entity对象。
那么，只读的对象和“操作中”的对象的区别在于，只读对象存在于DB中，“操作中”的对象存在于Repository中。
以上我说的，就应该是可以解决都放在内存中不现实的解决方案；总是处于“操作中”的对象会呆在Repository中，而其他的都在DB中。
语言没组织好，想好的继续说。
[该贴被brighthas于2011-07-10 18:26修改过]
不太同意“看一看”这种观点
理由：1、实际操作的时候，谁来界定对于对象是不是只是看一看，而不是看了之后可能要修改。或者说看与改之间不会那么经纬分明。
2、仓库类与数据库操作类的关系最大的区别就是概念上的区别。仓库类针对于领域、问题域的概念。比如“获取XXX”。数据库操作类是直接对于数据库的crud操作。当然，仓库类讲数据库操作类，比如DAO，作为自己的对象属性是非常可能的。因为具体执行诸如“获取XXX”的领域概念操作时，还是需要数据库操作类来执行。
那么，为什么需要这样脱开裤子放屁，用领域概念封装一遍数据库操作？其实，很大原因是要保持领域建模产物——领域模型的概念纯洁性。让软件项目参与各方获得一个清晰、稳定的概念模型（而不是掺杂程序员思维——导入数据库思维），需要在实施效率上作出一定的让步。
[该贴被showerxp于2011-07-19 23:11修改过]
打个比方吧，一群人呆着等候室，然后某处放着一本人员资料册子。
自然界中，找人做法有两种：
1、进去等候室，逐个问，符合资料要求的带出来；
2、查阅册子，根据要求，取出符合要求的身份证号码，再到房间里面，用身份证号码以1的方式找出人来。
而面向数据库的伪OO，则认为：房间中不存在人，需要某个册子中的人时，根据册子资料来人造人，人用完后，或修改资料再杀掉。可见这里的人，不是我们所关注的实体，我们所关注的是册子资料，而人只是一个可代替的资料容器。这种方式下，有必要“造人”么？完全是多此一举。我个人观点：这种方式的OO，完全只是打着OO的幌子而已。
其实OO技术，用到数据库，关键一点在于检索。数据库不再是实体存在的地方。而谈到持久化，在OO上说的是“记录一下实体的状态”或者“Command（CQRS）”而不是实体。只要停机了，实体就消失了，重新启动时，就是通过过去记录的状态或命令来还原停机前的领域环境。更生动的说法就是“上帝破坏了世界，人也就不存在了”，修复世界就是“上帝根据记忆还原破坏了的世界”。
真正的实体是存在数据活动的地方，现在来看是内存。
当然现在内存有限，我们“巧妙”地用数据库来不停的还原（世界的）实体。也正因为这样，才需要缓存和缓存策略来提高效率。
综上，“看一看”还是“改一改”都是对仓储内实体而言的。而数据库就是一本小册子，而不是实体集。
[该贴被SpeedVan于2011-07-26 17:03修改过]