当不使用真正的ORM时，这种问题很典型，并且没有灵丹妙药。对于使用iBatis（myBatis）的（不是很大的）Web应用程序来说，一种对我有用的简单设计方法是使用两层持久性：
愚蠢的底层：每个表都有其Java类（POJO或DTO），其 字段直接映射到表的column 。假设我们有一个
PERSON
表，其中的一个ADDRESS_ID
字段指向一个ADRESS
表；然后，我们将有一个PersonDb
仅包含addressId
（整数）字段的类；我们没有personDb.getAdress()
办法，只有平原personDb.getAdressId()
。因此，这些Java类非常笨拙（它们对持久性或相关类一无所知）。相应的PersonDao
类知道如何加载/持久化此对象。使用iBatis + iBator（或MyBatis + MYBatisGenerator）之类的工具可以轻松创建和维护该层。包含 丰富域对象的 更高层：这些 对象 通常是上述POJO 的 图形 。这些类还具有通过调用相应的DAO来加载/保存图形（可能很懒惰，可能带有一些脏标志）的智能。但是，重要的是，这些丰富的域对象不是一对一地映射到POJO对象（或DB表），而是使用 域用例 。确定每个图的“大小”（它不会无限增长），并且像特定类一样从外部使用。因此，并不是说您有一个丰富的
Person
类（带有一些不确定的相关对象图）被用于多个用例或服务方法。相反，您有几个丰富的类PersonWithAddreses
，PersonWithAllData
…每个人都包装了一个特定的，受限制的图，并具有自己的持久逻辑。这似乎效率低下或笨拙，在某些情况下可能是这样，但是经常发生这种情况，当您需要保存完整的对象图时，用例实际上受到限制。另外，对于表格报告之类的东西（（特定的SELECTS返回一堆要显示的列）），您将不会使用上述内容，而会使用直截了当的POJO（甚至可能是Maps）
