3

私は (Spring MVC フレームワークを使用して) MVC Web アプリケーションを構築していますが、特定の領域を設計する最善の方法に少し困惑しています。

アプリケーションは一連の Web サービスとやり取りする必要がありますが、これらの Web サービスはそれほど大きく設計されておらず、それ自体であまり抽象化されていません。基本的に、作成/更新/取得/削除操作ごとに Web サービス メソッドがあります。それぞれの「データ型」であり、それ以上の API はあまりありません。Web サービス クライアントは、必要なデータを作成するために、どのメソッドをどの順序で呼び出すかを知る必要があります。つまり、「トランザクション」ベースのメソッドはありません。

たとえば、単純に新しいユーザー アカウントを作成するには、合計 7 つの異なる Web サービス メソッドを呼び出して、必要なテーブルのすべてのレコードをセットアップする必要があります (userレコード、そのユーザーへの正しいレコードの追加、privilegesユーザーの詳細のセットアップbillingなど)。 .

これを抽象化し、アプリケーション内にカプセル化する最善の方法に苦労しています。アプリのほとんどは、標準的なフローに従います。

request ---> Controller <---> Service/Business-level object <---> DAOs for data access

アプリケーション内で、独自の「ドメイン オブジェクト」のセットを使用して、Web サービス WSDL で定義されたデータ型を表現および抽象化しているため、ドメイン ロジックは Web サービスの型に依存せず、抽象化および非表示にできます。私たちが好きな詳細。

私が意見を求めているのは、例として上で述べた「ユーザー作成プロセス」を設計するための最良の方法です。「通常のユーザー」を作成するプロセスには、前述のように 7 つの異なる Web サービスを呼び出すことが含まれますが、これはユーザーの「タイプ」の 1 つにすぎません。いくつかの異なるタイプのユーザーを作成できる必要があり、それぞれに異なる必要があります。呼び出される Web サービス。

現在、私はこの「通常のユーザー」の作成のみを、少しの概念実証としてUser設計UserDaoしました。 7 つの Web サービス メソッドについて言及しました。メソッドは によって呼び出されます。これは私のビジネス/サービスレベル クラスであり、 によって呼び出されます。getUser(name)createUser(User)WebServiceUserDaoUserDaocreateUser()UserCreationServiceSignupController

しかし、このロジックを拡張してさまざまなユーザー タイプを作成できるようにするには ( User.getType(). :

  1. 「ユーザー タイプ」ごとに1 つのUserDao実装を作成して、各「ユーザー タイプ」を作成するロジックを独自のクラスにカプセル化して、UserCreationServiceどちらUserDaoを使用するかを決定できるようにします。これは、1 つのサービス クラス: 多くの DAO に対応します。
  2. UserDaoアプリケーション全体がこれらの個々のタイプのそれぞれについて知る必要はありませんが、Web サービス/DB で作成する必要がある各「レコード」に対応する小さな部分に分割する必要がありますか? そしてUserCreationService、さまざまな異なる「ユーザータイプ」に対して異なる実装がありますか? つまり、対応するオブジェクトやドメイン オブジェクトが必要ない場合でも、この戦略には a PrivilegesDao、 aなどがあります。これは、多くのサービス クラス: 多くの DAO になります。BillingPlanDaoPrivilegeBillingPlan
  3. 「ユーザー タイプ」ごとに Web サービスを呼び出す必要があるすべてのロジックを単一のWebServiceUserDao? これには、非常に複雑なクラスを持つという欠点があります (そして、PMD は循環的複雑性についてすでに不満を持っています) が、このロジックはすべて 1 つのクラスにカプセル化され、API 全体の観点から見ると複雑さが軽減される可能性があります。

このアプリケーションでの目標の 1 つは、データの永続性の詳細を変更する必要がある場合に、DAO の実装を変更するだけで済むようにすることです。別の課金システムとのインターフェイスを開始する必要がある場合は、アプリケーションのどの部分も、DAO レベル以外で変更したくありません。

ご意見はありますか？「ビジネス ロジック」と「データ アクセス ロジック」が重複しているように見える場合、どこを分割するかを決定する際に、どのような戦略を使用しますか?

4

2 に答える 2

7

「ビジネスロジック」と「データアクセスロジック」が重複しているように見える場合に、それらをどこに分類するかを決定する際に、どのような戦略を使用しますか？

たぶん、2つではなく3つのレイヤーを持つことができます：「1つの余分なレベルの間接参照」。

最上位層には、データアクセスについて知らないビジネスロジックがある場合があります。このビジネス層は、、などUserのクラスと、Accountおよびなどのファクトリメソッドを使用User.getAccountsしAccount.getOwnersます。

最下層はデータアクセス層である可能性があります。これは、データ層が何であれ、そのラッパーまたはファサードです。

これらの2つのレイヤーの間には、ビジネスオブジェクト（ユーザーやアカウントなど）はわかっているが、ビジネスロジックはわかっていないレイヤーがあります。中間層はデータアクセス層を認識しています。中間層の仕事は、データアクセス層のAPIを使用してビジネスオブジェクトをI/Oすることです。

于 2009-01-28T14:58:17.670 に答える
0

「ビジネス/サービス層クラスと DAO の境界線をどこに引くべきかわかりません。」

私たち全員ではありませんか？

ORM ( iBatis、Hibernate、Toplinkなど) を使用することをお勧めします。独自の DAO を実装しないでください。

于 2009-01-28T16:00:55.733 に答える