中，它会对"未知"应用程序隐藏数据结构
我已经通读了这篇文章，试图理解为什么要在客户端和实体bean之间使用会话bean。这是因为通过让客户端直接访问实体bean，可以让客户端确切地了解数据库的所有信息吗？
因此，通过使用中间人（会话bean），您只会通过某种特定的方式实现业务逻辑，让客户端知道数据库的一部分。因此，只有数据库中与客户端相关的部分才可见。可能还会增加安全性。
上述说法是真的吗？
- 避免客户端与；业务对象，提高可管理性
- 减少细粒度的方法调用可以最大限度地减少网络上的方法调用，从而提供对客户端的粗粒度访问
- 可以具有集中的安全性&事务约束
- 更大的灵活性&应对变化的能力
- 只需要曝光&为客户端提供更简单的接口，隐藏底层复杂性和内部细节，以及业务组件之间的相互依赖性
您引用的文章完全过时。查一下日期，是2002年。
EJB中再也没有实体bean这样的东西了（它们目前被保留用于向后兼容性，但即将被完全清除）。实体豆哪里有尴尬的事；一个完全位于容器中的模型对象（例如Person），并且访问它的每个属性（例如getName、getAge）需要远程容器调用。
在这个时代，我们有JPA实体，它们是POJO，并且只包含数据。不要将JPA实体与这个古老的EJB实体bean混淆。它们听起来很相似，但却是完全不同的东西。JPA实体可以安全地发送到（远程）客户端。如果您真的担心实体中使用的名称会暴露您的DB结构，那么可以使用XML映射文件而不是注释，并使用完全不同的名称。
也就是说，如果需要的话，会话bean仍然可以完美地用于实现Facade模式。这种模式确实用于为客户端提供一个简化的、通常是受限的系统视图。只是使用会话bean作为实体bean的外观的想法已经完全过时了。
这是为了简化客户端的工作。Facade提供了一个简单的界面，并向客户端隐藏了模型的复杂性。只要facade不更改其接口，它还可以在不影响客户端的情况下更改模型。
它将应用程序逻辑和业务逻辑解耦
因此，实际的数据结构和实现可以在不破坏使用API的现有代码的情况下进行更改
当然，如果您将bean暴露在外部网络