したがって、私の前の質問への回答に基づいて、トランザクション中に複数の接続が開かれた場合、接続がすべて同じ接続文字列を持っていても、トランザクションは LTM から DTC に昇格します。
では、次の質問は、この「機能」を回避するためにどのような戦略を採用できるかということです。リソースの使用状況に基づいて、LTM を可能な限り使用するようにしたいと考えています。適切なオブジェクト指向のビジネス ロジック レイヤーでこれを行う唯一の方法は、データ アクセス レイヤーでリクエスト レベルの静的接続オブジェクトを作成し、リクエストが完了するまでそれを呼び出し間で共有することです (暗黙の知識はここにあります)。ビジネス オブジェクト エンティティは目立たず、どのような順序で呼び出されるかわからないということです。また、接続オブジェクトをビジネス オブジェクト レイヤーにバブルアップさせたくないという事実もあります。これは、データ ストレージの実装の詳細になるからです。別のレイヤーににじみます）。
n層システムのレイヤーカプセル化を完全に台無しにしないアイデアを誰か他の人が持っていますか?
私が使用したのは、TableAdapter 内のすべてのコマンドを更新する TransactionHelper クラスで、接続とトランザクションを、トランザクションを開始する TableAdapter からのものに置き換えます。Scott Lanford のブログCodeExperimentで、必要に応じて変更できるコードを見つけることができます。Ryan Whitaker も同様のアプローチをとっています。
LINQToSQL を使用するようになったため、この問題は発生しなくなりました。代替ソリューションとして LINQToSQL または nHibernate の使用を検討することをお勧めします。どちらも、ローカル トランザクションを適切にサポートします。
キャスパーが述べたように、DTC を回避するのは時期尚早かもしれませんが、それはかなりの重みです。単に新しいオブジェクトを返すように静的ファクトリを使用して接続を実装できます。問題があると判断した場合は、トランザクションを TLS (または ASP の場合は httpcontext) に保存できるメカニズムを実装できます。また、コードを変更する必要はありません。
この質問は実際に尋ねられ、回答されていますが、見つけたときに見つからないので、これを更新します。
接続、トランザクション、コマンド オブジェクトなど、DB 全体を管理するためのラッパー クラスを作成することをお勧めします。これは一種の非常に軽量な nHibernate です。このクラスは、executeStatement(...)、executeQuery(...)、addParameter(...)、startTransaction(...) などのメソッドを提供します。
トランザクションを開始するときに、同じトランザクションに関する後続のすべてのリクエストを結び付けることができる (必要に応じて一意の) 識別子を提供できます。次に、このラッパー クラスは、どのトランザクションがどの接続で実行されているかに対する静的マッピングを保持し、必要に応じて正しいものを自動的に使用するか、新しいものを作成します。
すべての永続性を一元化するため、このアプローチからいくつかの追加機能を取得できます。
DTC を回避しようと懸命に努力する理由は何ですか? この回答または前の回答では理由について言及されておらず、時期尚早の最適化症候群に苦しんでいるかのように見えます。