服务门面、分离实体和渴望获取

Question

服务外观通常实现为无状态会话 bean，这意味着它们可能返回的任何实体都将立即分离。这让我认为，作为服务外观业务方法的结果返回的任何实体都应该急切地获取其所有内部，因为在没有急切的情况下，服务客户端无法访问其内部。我想知道我在这方面是否正确，以及在某些情况下是否有可能更合适的其他方式。

谢谢

Answer 1

是的，您基本上是对的，一旦实体从创建它们的会话 bean 方法返回或从数据库中获取，它们就会被分离。这意味着在客户端层无法访问延迟加载的相关实体。 根据我的工作经验，我可以说有两种常见的情况。 第一个是业务层中的数据模型，用实体和企业 bean 实现，与客户端层中使用的数据模型完全不同；在这种情况下，最好的解决方案是创建所谓的 DTO（数据传输对象），即具有 get 和 set 方法的普通 java 对象，并使用它们在两层之间传输数据。 这种方法的主要缺点是编写 DTO 可能是一项冗长、无聊且容易出错的任务，而且它们要么不实现业务逻辑，是纯 bean，要么必须在两个层中复制逻辑。如果两层中的数据模型相同并且一个会重用行为，则尤其如此。 这导致我们采用第二种方法，即构建一个独特的数据模型，其中包含要在业务层和客户端层共享的实体，具有更少的代码编写和逻辑重用的明显优势。然而，为了将分离的实体从一层传递到另一层，您只有两个选择：要么将所有关系声明为急切的，有可能在内存中加载过多的对象，尤其是当您的实体紧密互连时，或者让它们懒惰并编写您的外观方法要小心，以便在返回之前加载所有需要的字段。 我最近面临一个现实世界的项目，其中实体连接图几乎是一个完整的，这促使我们更喜欢延迟加载关系，并避免编写太多代码行来填充每个所需的相关实体在服务外观方法中返回实体，我们求助于 DTO，为每一类客户端用例建模其中一个，并使用泛型方法自动将实体转换为相应的 DTO。