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 タグごとに複数回呼び出すことができることをどのように知っていますか?
  • そしてリストは続きます...

私は個人的にコントラクトという用語を使用して、制約の完全なセットを指します。インターフェイスは、型システムの観点から見たメソッドのシグネチャのみを提供します。

このトピックに興味がある場合は、design by contractを参照することをお勧めします。コンポーネント間の契約をより正確に形式化するという考えは、長い間存在していました。

したがって、私の答えは次のようになります。たとえそうであったとしても、さらに多くの情報が必要だからです。

于 2010-01-26T20:15:12.077 に答える