1

事务语义和状态完整性在 EJB3 中被视为实现细节。实现可以决定是使用 bean 还是容器管理的事务。它可以决定容器管理事务的类型。它可以决定它是有状态的还是无状态的。

但是，从逻辑上讲，这些都是重要的接口细节。示例： (a) 使用 bean 管理事务的 bean 不能调用使用容器管理事务的 bean。(b) 无状态 bean 不能调用有状态的 bean。

当呈现一个 EJB3 接口时，您不知道它需要什么样的事务语义。同样，您不知道它是有状态的还是无状态的。您需要额外的实施细节。示例：文档。

在运行时，可以动态实例化不同的 bean 和调用链。因此可能会出现无效状态。现在 - 容器可以捕获这些情况；但为什么要等到运行时？

为什么事务语义和状态完整性要求不是接口的一部分？

4

1 回答 1

1

事务语义和状态完整性在 EJB3 中被视为实现细节。实现可以决定是使用 bean 还是容器管理的事务。它可以决定容器管理事务的类型。它可以决定它是有状态的还是无状态的。

我理解从客户的角度来看确实很重要的状态管理的观点。

关于交易，它有点棘手。

  • 交易的类型（bean-managed或container-managed）是实现细节（我不确定你的例子（a））。
  • 传播语义不是. _ （required、mandatory、none等）。

现在 - 容器可以捕获这些情况；但为什么要等到运行时？

即使所有这些都存在于接口中，类型系统仍然不足以在编译类型时强制执行规则。

无论如何，您都需要一个工具来根据它们的应用语义检查这些约束。IDE 可以在解析注解时执行此操作，容器可以在部署模块时执行此操作，更糟糕的是它在运行时失败。

为什么事务语义和状态完整性要求不是接口的一部分？

java接口只携带一组关于组件正确使用的有限信息，无论是类、bean 还是 API。大多数组件的整体契约比接口中暴露的要复杂得多。

例子：

  • 线程安全：如果不查看文档，您如何知道特定类是否是线程安全的？
  • ContentHandler.characters(): 你怎么知道每个 XML 标签可以多次调用它？
  • 而这样的例子不胜枚举...

我个人使用术语合同来指代完整的约束集。从类型系统的角度来看，接口只给了我方法的签名。

如果您对该主题感兴趣，我建议您按合同看设计。更精确地确定组件之间的合同的想法已经存在很长时间了。

所以我的回答是：因为即使是这样，你仍然需要更多信息。

于 2010-01-26T20:15:12.077 回答