私はこのトピックについて静かに多くの読書をしましたが、まだ未解決の質問がいくつかあります. 次のシナリオを想像してください。
【プレゼンテーション層】
2 つのアクセス ポイントを持つアプリケーションを開発したいと考えています。
- Web フロントエンド (View + Controller ベース)
- サービス API
したがって、ビジネス ロジックをこれらのさまざまなプレゼンテーション ビューから分離して再利用することは完全に理にかなっています。
[データレイヤー]
階層化されたアーキテクチャの反対側には、データ層があります。
- 一部のORMフレームワークによってマップされたデータを表すドメイン/モデルオブジェクト
- 作成、読み取り、更新、削除 (crud) 機能を提供するデータ アクセス オブジェクト (dao)
このレイヤーは、データへのアクセスに関するものです。すべてのデータ アクセス固有のロジックをこのレイヤーに保持して、別のストレージ システムで簡単に置き換えることができるようにします。
【サービス層】
これは、すべてのビジネス ロジックが発生するデータ層とプレゼンテーション層の間の層です。
このスレッドを言語やフレームワークに固有のものにしたくない一方で、中央のトランザクション処理 (ロールバック、コミット) でそれを実現する方法を知りたいです。それでは、トランザクション管理の便利なフレームワークとして spring を使用すると仮定しましょう。
1.取引を処理するのに最適な場所はどこですか???
1 つのトランザクション中に複数のオブジェクトにアクセスして変更する必要があるため、明らかにデータ アクセス オブジェクトの一部ではありません。したがって、Spring フレームワークで提案されているように、サービス レベルでトランザクション処理を適用する必要があります。
ただし、ビジネス ロジックが次のようなことを行うとします。
- a）データベースからいくつかのオブジェクトをリクエストします
- b) これらのオブジェクトに関するリモート情報を要求する
- c）データベース内のオブジェクトのステータスを更新します
操作 b には未定義の時間がかかる場合があるため、貴重なシステム リソースが割り当てられるため、この操作にトランザクションをスパンすることは望ましくありません。そのため、ビジネス ロジックの一部を残りから分離する必要があります。
これは、サービス レイヤーを 2 つのレイヤーに分離する必要があることを意味しますか?
2. データの変更と取得方法 ???
データを表示するには、プレゼンテーション層がドメイン オブジェクトを認識する必要があります。daos を使用することで、サービス層はこれらのオブジェクトへのアクセスをプレゼンテーション層に許可します。このアプローチには 2 つの問題があります。
a) 便利な ORM フレームワークとして hibernate が使用されているとします。その後、依存関係は遅延ロードされます。これは、他のほとんどの ORM フレームワークにも当てはまります。そのため、複雑なオブジェクトにアクセスしようとしているビュー コードは、トランザクション コンテキストがサービス レイヤーによって終了されたため、遅延読み込み例外が発生する可能性があります。
この種の状況を処理する正しい方法は何ですか？
b) コントローラーは通常、何らかのフレームワーク マジックを使用して、Web フォームで行われた変更をモデル オブジェクトに直接適用します。これもトランザクション コンテキストの外側にあるため、サービス レイヤーは、モデル オブジェクトを新しいトランザクションに再アタッチして保存する機能を提供する必要があります。
これは本当に正しい方法ですか？
あなたの答えを楽しみにしています...