【发布时间】：2011-09-04 02:19:26
【问题描述】：
我已经通读了这个article，试图了解为什么您希望在客户端和实体 bean 之间有一个会话 bean。是不是因为让客户端直接访问实体 bean 会让客户端准确地知道数据库的所有信息？
因此，通过使用中间人（会话 bean），您只能通过以某种特定方式实现业务逻辑来让客户端知道数据库的一部分。因此，只有与客户端相关的部分数据库是可见的。可能还会增加安全性。
以上说法属实吗？
【问题讨论】：
【发布时间】：2011-09-04 02:19:26
【问题描述】：
- 避免客户端和业务对象之间的紧密耦合，提高可管理性。
- 减少细粒度的方法调用，从而最大限度地减少网络上的方法调用调用，为客户端提供粗粒度的访问。
- 可以有集中的安全和交易限制。
- 更大的灵活性和应对变化的能力。
- 只公开所需的并向客户端提供更简单的接口，隐藏底层复杂性和内部细节，业务组件之间的相互依赖关系。
【讨论】：
您引用的文章完全已过时。检查日期，是从 2002 年开始的。
EJB 中不再有实体 bean 之类的东西（它们目前被保留是为了向后兼容，但正处于被完全清除的边缘）。实体 bean 哪里尴尬的事情；一个完全存在于容器中的模型对象（例如 Person），并且访问它的每个属性（例如 getName、getAge）需要远程容器调用。
在这个时代，我们有 JPA 实体，它们是 POJO 并且只包含数据。不要将 JPA 实体与这个古老的 EJB 实体 bean 混淆。它们听起来很相似，但却是完全不同的东西。 JPA 实体可以安全地发送到（远程）客户端。如果您真的担心实体中使用的名称会暴露您的数据库结构，您可以使用 XML 映射文件而不是注释并使用完全不同的名称。
也就是说，如果需要，会话 bean 仍然可以完美地用于实现外观模式。这种模式确实用于为客户提供简化且通常受限的系统视图。只是将会话 bean 用作实体 bean 的 Facade 的想法已经完全过时了。
【讨论】：
-
提出外观模式的想法仍然有效，还是现在也不同了？因为即使是您在 Oracles 网站上找到的文章也是 2002 年的。
-
当然，Facade 模式仍然是有效的模式。与几乎所有模式一样，您不应该盲目使用它。仅在遇到该模式旨在解决的问题时才使用它。
-
那么文章还没有完全过时。
-
好的，如果您阅读它是为了了解 Facade 的概念，那是肯定的。它没有过时。 2090 年的人们可能仍然可以为此阅读这篇文章。然而，正如我所提到的，这篇文章的主要动机似乎是使用专门用于实体 Bean 的外观。 那个已经过时了。对我来说，这篇文章似乎不是关于解释 Facade 模式的一般文章，但如果它对你有用，请享受它；）
是为了简化客户端的工作。 Facade 提供了一个简单的界面，并向客户端隐藏了模型的复杂性。只要外观不改变其接口，它还可以在不影响客户端的情况下更改模型。
【讨论】：
它将应用程序逻辑与业务逻辑解耦。
因此，实际的数据结构和实现可以在不破坏现有代码的情况下使用 API 进行更改。
当然，如果您将 bean 暴露给外部网络，它会对“未知”应用程序隐藏数据结构
【讨论】：