1

1 つのビジネス オブジェクト (TO) で作業したい状況があります。ただし、この TO を構成するデータは、次の 2 つの異なるデータ ソースから取得されます。

  • JPA と 1 つのエンティティを介してアクセスされるアプリケーションのデータベース
  • Web サービスを介してアクセスされる古いシステムのデータ

このプロジェクトの後の段階で、すべてのデータがアプリケーションのデータベースに移動されます。したがって、このすべてのデータを表す 1 つのビジネス オブジェクト (TO) が必要です。

私のアプローチは次のいずれかです。

1) エンティティ用の DAO と旧システム用の別の DAO を用意します。次に、これらの上にさらに別の DAO を追加します。これにより、アプリケーションの残りの部分で使用するビジネス オブジェクトが作成されます。

2) エンティティから一部のデータを取得し、旧システムから一部のデータを取得する DAO を 1 つだけ持つ。

これについてどう思いますか？

4

2 に答える 2

2

Dao's（エンティティ、古いシステム）の上にサービスレイヤーを導入し、Springすべてを（使用していると仮定して）Dao'sサービスに注入する必要があります。オプション 1 の方が優れていますが、サービス内に 2 つの Dao を作成し、アプリケーション全体で使用されるビジネス転送オブジェクトを作成するだけです。ワークフローは、UI -> PersonService -> Dao1 (app db)、Dao2 (Webservice) になります。PersonService には、必要なビジネス ロジックがあればそれがあります。さらに、PersonService 内に PersonDaoFactory を作成して、Dao の内部サービス層の作成を抽象化できます。したがって、最後に、コントローラーまたは UI レイヤーから以下のようなものが得られます (ドメイン モデルがわからないため、架空のシナリオです)。

Person person = personService.findUserById(personId);
Product product = person.getProducts();
Comment comment = person.getComments();
Friends friends = person.getFriends();

さらに、多くの DAO が解決し、1 つの大きな DAO が解決しない問題を考えてみてください。

于 2013-03-08T19:46:49.370 に答える
0

データの知識なしにそれに答えるのはかなり難しいです。私がすることは、2 つの dao を用意することです。1 つは db 用で、もう 1 つは webservice 用です (dao というよりもサービスと呼びます)。後者を使用して、JPA dao によって取得されるエンティティにプロパティを追加します。後で webservice のサービス/dao を削除し、JPA dao を進化させます。

そして、他の回答で述べたように、サービスからこれらのdaoを使用してこれを抽象化する必要があります。したがって、あなたの最初の解決策は私には良く聞こえます。

于 2013-03-08T19:47:18.090 に答える