7

おおよそ次のような 3 層アーキテクチャがあります。

クライアント -> ビジネス -> データ

トランザクションはどこから開始するのが理想的ですか?

ある考え方では、トランザクションはデータ レイヤーの最上部からのみ開始する必要があります。ビジネス レイヤーは、ビジネス ロジックを使用してビジネス オブジェクトを操作するだけで、トランザクションについてはまったく知りません。ビジネスは、オブジェクトを操作するためにすべての作業を行い、それらをデータ層に渡して永続化します。これは、下位層に適用されるやや RESTful な哲学です。

別の考え方では、トランザクションはビジネス レイヤーの最上部から開始する必要があります。論理的な作業単位にはデータ ロジックだけでなく、ビジネス ロジックが含まれることがあるため、ビジネス レイヤーはデータ レイヤーではなく論理的な作業単位を定義します。

私は、トランザクションの懸念をできるだけ低くするという考えが好きです。しかし、単なる CRUD 操作でない限り、ビジネス ロジックをデータ レイヤーから除外するには、余分な労力と設計上の課題が必要になることもわかっています。大ハンマーで RESTful 設計パターンを適用すると、アプリケーションで CRUD 以外の操作をほとんど行わないようにすることができます。

必要に応じて複数のビジネス オペレーションを組み合わせることができるように、クライアントがトランザクションを開始できるという第 3 の考え方もあります。しかし今、クライアントは作業単位を定義していますか? それはビジネス上の問題ではありませんか?

第 4 の考え方によると、私のクライアントは、クライアントの外部で開始された XA トランザクションに参加できる単なる SOA コンポーネントである可能性があります!!

私たちの開発者は、「好きな場所でトランザクションを開始する」だけでなく、より具体的な基準を求めています。

この件に関して意見や提案はありますか?

ありがとう!

4

2 に答える 2

2

の中に

クライアント -> ビジネス -> データ

ビジネス レイヤーでトランザクションを定義することをお勧めします。ビジネス サービスが新しいトランザクションを開始するか、既に開始されている場合は既存のトランザクションに参加するように、トランザクションを定義することをお勧めします。これにより、ビジネス サービスが別のビジネス サービスによって呼び出される場合に対処できます。

ビジネス レイヤーが同じ要求の一部として複数のデータ レイヤー呼び出しを行う場合、データ レイヤーでのトランザクション境界の設定は失敗します。

client1-> business1 => data1 , business1 => data2

于 2013-04-17T18:00:56.033 に答える