我有一个使用 Spring 的项目，它被分解成几十个 DAO 和相关的 DTO。我正在使用 JdbcTemplate，但仅此而已，因为它正是我满意的抽象级别。
我目前正在我的 DTO 上执行延迟加载，方法是在它们的 getter 中放置一些相当多毛的代码。
基本的样板逻辑是： 1. 如果字段不为 null，则返回其值并退出 2. 联系适当的 DAO 并获取相关的 DTO 3. 将它们存储到下一次。
它工作得很好，除了我的低级 DTO 与一大堆 DAO 相结合并且不是那么 POJOey。
如果我将逻辑放在 DAO 中，则会出现另一种代码气味，因为它将同时处理其 DTO 的 CRUD 和延迟加载，并且据我所知，对象应该有一个单一的责任。
我希望有一个相对简单的 Spring 方法，我可以使用它在 DAO 和 DTO 之间注入一个延迟加载器对象来实现这一点，但任何其他解决方案都对我有用。
有任何想法吗？
将 DAO 包裹在 DAO 周围会更容易……这取决于您想要引入多少模型。DTO 通常不用于将一对多的操作作为两个或多个单独的数据库/dao 调用。在那种情况下，你真的想要一个 ORM。既然你在寻找一个道的答案......
没有什么能阻止您将 DAO 链接在一起，为您提供一个 DTO。将 DTO 连接到 DAO 会更容易。它不是真正的服务层，它只是 DAO 的构建块。所以你可能有一个 PersonDao 和一个 TelephoneNumberDao。一个人可以拥有多个电话号码，因此您也可以拥有 PersonModelDAo，它在后台使用 PersonDao 和 TelephoneNumberDao 来完成工作。
或者，避免整个问题，不要尝试在 DTO 级别映射人员和电话号码之间的 1-N。只需让您的 UI 对正确的 DAO 进行正确的调用。在使用 DTO 时，我实际上更喜欢这个。
引入一个服务层来包装你的 DAO 并处理诸如此类的问题是很常见的。如果您担心在 DTO 中放入太多样板代码来处理延迟加载，也许使用 AOP 可能是实现此目的的一种方法。您可能想查看 AspectJ 并在编译时或加载时进行编织。由于您将直接修改字节码，因此您不必担心基于代理的 AOP 的性能开销。