服务外观，独立实体和渴望获取

Question

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

谢谢

Answer 1

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