1

私は医療費請求アプリケーションを書いていて、MVC (Spring) を初めて使用しているので、適切なアプローチを得るのに苦労しています。考え/コメントをいただければ幸いです。

私の「ドメイン」クラス

  • 医者
  • 忍耐強い
  • 請求
  • ビジネスの論理

私のコントローラークラス

  • リスト患者
  • 編集患者
  • 患者の検索
  • 提出請求

私のリポジトリクラス

  • IPPatientDao
  • IDoctorダオ
  • アイクレイムダオ

私のアプリケーションは非常に「ルールが重い」ものです。たとえば、医師は他の医師の患者を削除できません。何かに対して請求されている場合、患者を削除することはできません。

これらのルールは、特にルールを複数のコントローラーで使用する必要がある場合は、汚いと感じるコントローラーに取り込まれるべきではないと思います。同様に、私の DAO オブジェクトは読み取りと書き込み専用であり、検証用ではないと感じています。その結果、頭脳を持つ BusinessLogic オブジェクトを作成しました。だから私は次のようなものを呼び出すことができます:

businessLogic.deletePatient(患者、医師); // true/false を返し、メッセージを設定

これにより、ログインしている医師が特定の患者を削除する権限を持っているかどうかがチェックされます。

私には、これがすべてを整頓する最善の方法のように思えます。

良いまたは悪い？何が良いでしょうか？

4

2 に答える 2

1

このドメイン モデルには、保険会社とやり取りするための機能や、買掛金/売掛金システムのインターフェイスが含まれていないため、どうしようもなく素朴に見えます。しかし、初期段階にあり、構築する前に単純なモデルを試しているだけかもしれません。

BusinessLogic オブジェクトを具体化するとは思いません。一般的すぎる。

Spring を使用している場合は、ルールを適用するためにアスペクト指向プログラミングをより有効に活用できないかと思います。

JSR-94 のSpring サポートが役立つかどうかを調べます。ルール エンジンを使用して、オブジェクトに複雑な動作を埋め込むことができるかもしれません。

最良のアドバイスは、Spring が推奨する階層化イディオムの章と節を読むことです。

  1. Struts アクション < スプリング コントローラ;
  2. ビジネスクラス～スプリングサービス
  3. DTO の Nix - 通常、Spring では使用されません。これらは、EJB 1.0 からの残りのアンチパターンです。
  4. DAO/リポジトリは、Spring のイディオムをお勧めします。JPAは物事を一般的に保ちます。
于 2009-06-05T23:40:03.880 に答える
1

私はMVCアーキテクチャを感じています...ここにLAyersの流れがあるはずです....

a) アクション クラス..Struts のように...Web ページのすべてのパラメータはこのクラスで処理する必要があります...すべての検証はフォームのバリデータによって処理する必要があります...

b）このアクションクラスから、特定のアクションのすべてのビジネスロジックを実行するビジネスクラスを呼び出します....たとえば、患者に請求します...これにより、それに関連付けられた医師が取得され、そのために医師にいくらかのコミッションが与えられます...

c）DTOレイヤー...アプリケーションのすべてのクラスのゲッターセッター...すべてのレイヤーで使用できます...患者、請求書、医師などはいくつかの例です...

d) DAO レイヤー..データベースと対話する oe... 休止状態、JDBC などを使用して対話できます...すべてのクエリが記述されています...すべてのキャッシュなどを行います...

したがって、レイヤーは

アクションはビジネス層を呼び出し、DAO層を呼び出します..DTOはすべての層で使用でき、データを表示するために要求オブジェクトとしてJSPページに送信することもできます...

于 2009-06-05T23:40:13.867 に答える