2

我已经通读了这篇文章，试图理解为什么您希望在客户端和实体 bean 之间有一个会话 bean。是因为通过让客户端直接访问实体 bean，您会让客户端确切地知道数据库的所有信息吗？

因此，通过使用中间人（会话 bean），您只会通过以某种特定方式实现业务逻辑来让客户端知道数据库的一部分。所以只有与客户端相关的部分数据库是可见的。可能还会增加安全性。

上述说法是否属实？

4

4 回答 4

4
  • 避免客户端和业务对象之间的紧密耦合，提高可管理性。
  • 减少细粒度的方法调用，可以最大限度地减少网络上的方法调用调用，为客户端提供粗粒度的访问。
  • 可以有集中的安全和交易限制。
  • 更大的灵活性和应对变化的能力。
  • 只向客户端公开所需的接口并提供更简单的接口，隐藏底层的复杂性和内部细节，业务组件之间的相互依赖关系。
于 2011-05-29T07:00:43.833 回答
2

您引用的文章完全过时了。检查日期，它是从 2002 年开始的。

EJB 中不再有实体 bean 这样的东西（它们目前被保留是为了向后兼容，但即将被完全清除）。实体 bean 哪里尴尬的事情；一个完全存在于容器中的模型对象（例如 Person），并且访问它的每个属性（例如 getName、getAge）需要远程容器调用。

在这个时代，我们有 JPA 实体，它们是 POJO 并且只包含数据。不要将 JPA 实体与这个古老的 EJB 实体 bean 混淆。它们听起来很相似，但却是完全不同的东西。JPA 实体可以安全地发送到（远程）客户端。如果您真的担心实体中使用的名称会显示您的数据库结构，您可以使用 XML 映射文件而不是注释并使用完全不同的名称。

也就是说，如果需要，会话 bean 仍然可以完美地用于实现 Facade 模式。这种模式确实用于为客户提供简化且通常受限的系统视图。只是将会话 bean 用作实体 bean 的外观的想法已经完全过时了。

于 2011-05-28T21:46:21.833 回答
1

这是为了简化客户的工作。Facade 提供了一个简单的界面，并向客户端隐藏了模型的复杂性。只要外观不改变其接口，它还可以在不影响客户端的情况下更改模型。

于 2011-05-28T21:17:46.697 回答
0

它将应用程序逻辑与业务逻辑解耦。
因此，实际的数据结构和实现可以在不破坏现有代码的情况下使用 API 进行更改。
当然，如果您将 bean 暴露给外部网络，它会对“未知”应用程序隐藏数据结构

于 2011-05-28T21:22:32.740 回答