2

この記事を読み、クライアント Bean とエンティティ Bean の間にセッション Bean が必要な理由を理解しようとしました。クライアントがエンティティ Bean に直接アクセスできるようにすることで、クライアントにデータベースのすべてを正確に知らせることができるからですか?

したがって、仲介者 (セッション Bean) を使用することで、特定の方法でビジネス ロジックを実装することによって、クライアントにデータベースの一部のみを知らせることができます。そのため、クライアントに関連するデータベースの一部のみが表示されます。おそらくセキュリティも向上します。

上記の説明は本当ですか？

4

4 に答える 4

4
  • クライアントとビジネス オブジェクト間の密結合を回避し、管理性を向上させます。
  • 細粒度のメソッド呼び出しを減らすと、ネットワーク経由でのメソッド呼び出しの呼び出しが最小限に抑えられ、クライアントへの粗粒度のアクセスが提供されます。
  • セキュリティとトランザクションの制約を一元化できます。
  • 柔軟性と変化への対応力が向上します。
  • 必要な部分だけを公開し、よりシンプルなインターフェイスをクライアントに提供し、根底にある複雑さと内部の詳細、ビジネス コンポーネント間の相互依存性を隠します。
于 2011-05-29T07:00:43.833 に答える
2

あなたが引用した記事は完全に古くなっています。日付を確認してください、それは2002年からです。

EJB にはエンティティ Bean のようなものはもうありません (現在は下位互換性のために保持されていますが、完全に削除される寸前です)。扱いにくいエンティティ Bean。コンテナ内に完全に存在し、そのすべてのプロパティ（getName、getAge など）へのアクセスにリモート コンテナ呼び出しが必要なモデル オブジェクト（Person など）。

この時代には、POJO であり、データのみを含む JPA エンティティがあります。JPA エンティティーをこの古い EJB エンティティー Bean と混同しないでください。それらは似ているように聞こえますが、まったく異なるものです。JPA エンティティは (リモート) クライアントに安全に送信できます。エンティティで使用されている名前によって DB 構造が明らかになることが本当に懸念される場合は、注釈の代わりに XML マッピング ファイルを使用して、まったく異なる名前を使用できます。

とはいえ、セッション Bean は、必要に応じて Facade パターンを実装するために完全に使用できます。このパターンは実際、クライアントにシステムの簡略化された、しばしば制限されたビューを提供するために使用されます。セッション Bean をエンティティ Bean の Facade として使用するという考えは完全に時代遅れです。

于 2011-05-28T21:46:21.833 に答える
1

クライアントの作業を簡素化するためです。Facade はシンプルなインターフェースを提供し、モデルの複雑さをクライアントから隠します。また、ファサードがインターフェースを変更しない限り、クライアントに影響を与えずにモデルを変更することもできます。

于 2011-05-28T21:17:46.697 に答える
0

アプリケーションロジックとビジネスロジックを切り離します。
したがって、実際のデータ構造と実装は、APIを利用して既存のコードを壊すことなく変更できます。
もちろん、Beanを外部ネットワークに公開すると、「不明な」アプリケーションからデータ構造が隠されます。

于 2011-05-28T21:22:32.740 に答える