7

与えられた:

  1. Spring MVC - 休止状態。
  2. コントローラ -> サービス -> DAO
  3. 今、DBから何かを取得するメソッドがあり、これを行うたびに、「processList」という別のメソッドを実行する必要があります（一部の画面パラメーターに応じてリスト内の値を変更するようなものです）。

質問：

  1. この「processList」を何層に置くか？(コントローラー、サービス、または DAO? とその理由)

私は今、いくつかのj2eeの説明が本当に必要です.MVCは言語間で同じであることを知っていますが、確認する必要があります:)これを.netで行っている場合、間違いなくこれをサービスに投入していたでしょう.

4

1 に答える 1

19

これは、正確に何processListをしているかに大きく依存します。黄金律はありません。私が従おうとするいくつかのルールは次のとおりです。

  1. 同じレイヤー上のメイン オブジェクト間で呼び出しを行わないでください。
    • ManagementServiceImplを呼び出すべきではありませんNotificationServiceImpl。
  2. オブジェクト間の循環依存関係を作成しないでください。
    • これは上記のものと非常によく似ています。
  3. 複数のメイン オブジェクトでロジックを繰り返している場合は、コードを再構築し、特殊な論理クラスに抽出してみてください(これにより、単体テストも改善されます)。
    • たとえばUserUpdateHandler、またはNotificationDispatcher（これらはまだサービスレイヤーによって所有されています->他の誰もそれらを呼び出すことはできません）...
  4. 論理的に属する場所にコードを配置します。
    • いくつかのクラスが何かをする必要があるという事実に気を取られないでください。コードの適切な場所ではない可能性があります。
  5. 必要になる前に、完全に一般化されたコードを書かないでください。
    • これは時期尚早な一般化と呼ばれ、時期尚早な最適化に似た悪い習慣です。数行のコードを保存すると、将来的に髪を抜くことにつながる可能性があります。
  6. 常に一般化できるコードを記述します。
    • これは前のものと矛盾しません。これは、常に一般化を念頭に置いて書いてください。ただし、必要がない場合は、わざわざ書く必要はありません。先を考えますが、必ずしも先を行く必要はありません。
  7. ビジネス ロジックはサービス レイヤーに、データ永続化ロジックはデータ レイヤーに、ユーザー インタラクション ロジックはプレゼンテーション レイヤーに残します。
    • サービス層でユーザー入力を解析しようとしないでください。これは、e ショップ アプリケーションでの最終価格のカウントがプレゼンテーション層に属していないのと同様に、そこには属していません。

の例processList:

  • 例 I - 経由で追加のリレーションを取得するHibernate#initialize
    • これは、実際にはサービスと DAO レイヤーの間にあるものです。古いプロジェクトでは、特殊なFetchHandlerクラス (サービス レイヤーが所有) がありました。新しいプロジェクトでは、これを完全に DAO に任せています。
  • 例 II - リストを調べて、ビジネス検証メッセージを結果に 追加する
    • サービス層、間違いなく
  • 例 III - リストを確認し、検証エラーに基づいて UI メッセージを準備する
    • プレゼンテーション層

サイドノート：

  • MVC は、3 層アーキテクチャーとは別のものです。
  • Mモデルは、3 つのレイヤーすべてにまたがっています。プレゼンテーション レイヤーには、VビューとCコントローラーの両方が含まれます。
于 2013-06-16T08:24:37.047 に答える