0

私は、一部の Tuxedo サービスを同等の JDBC 呼び出しに置き換えるという任務を負っています。

単一の Tuxedo サービスを考えて、既存の Tuxedo DAO と同じインターフェイスを実装する JDBC DAO を作成することから始めました。これで、新しいサービス レイヤーからメソッドを呼び出しています。JDBC トランザクションを処理するために、サービス層で Spring @Transactional アノテーションを使用する予定です。

Tuxedo はトランザクションを内部で処理するため、単一の Tuxedo DAO メソッド呼び出しは、新しいサービス層から呼び出される JDBC DAO での複数のメソッド呼び出しに匹敵します。

以上のことから、Tuxedo DAO が実際にはサービス レベルのエンティティであることは理にかなっています。それは理にかなっていますか？

サービス/DAO レイヤーの観点からこれをレイアウトする最善の方法についての考えをいただければ幸いです。従来の目的のために Tuxedo DAO を保持する必要がありますが、必要に応じてこれをサービス層にリファクタリングすることは問題になりません。

ありがとうジェイ

4

1 に答える 1

1

良い、

それは非常に理にかなっています。実際、Tuxedo サービス (それが DB アクセスのみであるか、それ以上のビジネス ロジックがあるかによって異なります) は、単純な DB-DAO または何らかのサービス (EJB、WebService など、標準テクノロジに応じて) に置き換えることができます。企業で使用されます)。

サービスを分類することから始めて、それぞれをどうするかを決定し、いくつかの戦略を修正できるようにします。「DB-DAO」、「OTHER-DATASTORE-DAO」、「MORE COMPLEX SERVICE」など。

この作業を行った後、ダイレクト DAO とサービスを構築できます。別のインフラストラクチャにサービスをデプロイすることにした場合 (スケーリングの問題、または単に多くのアプリケーションがそれらを使用するため、明確な可視性を維持したい場合)、DAO を記述してそれらを使用し、元の呼び出しインターフェイスを尊重することができますが、背後にある新しい実装。

よろしく

于 2013-03-28T15:08:07.077 に答える