当不使用真正的ORM时，这种问题很典型，并且没有灵丹妙药。对于使用iBatis（myBatis）的（不是很大的）Web应用程序来说，一种对我有用的简单设计方法是使用两层持久性：
愚蠢的底层：每个表都有其java类（POJO或DTO），其 。假设我们有一个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）
602392714
清零编程群