75

MVC を銀行にたとえて説明しているブログ記事を読みました。MVC フレームワーク (CakePHP) を使用した Web アプリケーション開発の経験が数か月あるため、基本は理解できましたが、ロジックを配置する場所に欠陥のあるアプローチを取っていると思わせるテーマが見え始めました。

  • ファット モデル、スキニー コントローラ
  • モデルにできるだけ多くのビジネス ロジックを保持する

私のアプリでは、モデルは拒食症で、コントローラーは肥満です。コントローラーにはすべてのビジネス ロジックがあり、モデルには関連付けと検証ルール以外には何もありません。

コントローラーをスキャンすると、モデルに含まれるはずの多くのロジックを特定できるようになりました。

  • アプリにはアイテムを含むリストがあり、アイテムをランク付けできます。リストをランク順に並べ替えるソートロジックはコントローラーにあります。
  • 同様に、アイテム (Item モデル) にもイメージ (Image モデル) があります。各アイテムにはデフォルトの画像があります (items テーブルの image_id で指定)。アイテムが画像とともに表示される場合、デフォルトの画像が最初に表示されます。コントローラーでこれを行うロジックがあります。
  • リストが表示されると、関連するリストがサイドバーに表示されます。どのリストが関連しているかを判断するロジックはコントローラーにあります。

今私の質問に：

  1. 上記の例で、モデルに属するコントローラーに現在あるロジックのインスタンスであると考えて、正しい方向に進んでいますか?
  2. モデルに入れる必要がある、Web アプリに共通のロジックの他の領域は何ですか?
  3. この問題を特定し、設計パターンを変更することは、戦いの半分であると確信していますが、上で示した例を取り上げて、そのロジックをモデルに移そうと決めたとしても、どこから始めればよいかわかりません。ここにコードを投稿したり、優れた学習リソースにリンクしたりして、誰かが私を正しい方向に向けることができますか? CakePHP 固有のヘルプは素晴らしいですが、MVC で十分であると確信しています。
4

2 に答える 2

55

「正しい」答えを出すのは少し難しいです。それらのいくつかはフレームワークの詳細を扱っているからです (使用しているものに関係なく)。

少なくとも CakePHP に関しては:

  1. はい

  2. データまたはデータ操作を扱うものはすべてモデルに含める必要があります。CakePHP に関して言えば、単純な find() メソッドはどうでしょうか? ... 他の場所で必要になる可能性のある何か「特別な」(つまり、特定の「条件」のセットを思い出す) ことを行う可能性がある場合、それはモデルのメソッド内にラップする良い言い訳です。

  3. 残念ながら、簡単な答えはありません。コードのリファクタリングは自然なプロセスです。時々、「聖なるマカロニ...それはモデルにあるはずです！」と目を覚ますだけです。（まあ、あなたはそうしないかもしれませんが、私は持っています:)）

于 2009-01-21T23:03:18.313 に答える
19

ロジックが適切な場所にあるかどうかを確認するために、少なくとも次の 2 つの「テスト」を使用しています。

1) 単体テストを作成する場合、テストを実行する 1 つの「実際の」オブジェクト (= 実稼働環境で使用しているオブジェクト) のみを作成し、おそらくいくつかの値オブジェクトを除いて、他の多くのオブジェクトを含めないようにするのは簡単です。テストを実行するために実際のモデル オブジェクトと実際のコントローラー オブジェクトの両方が必要な場合は、機能を移行する必要があることを示している可能性があります。

2) 自問自答してください: これらのクラスを使用する別の方法を追加した場合、ほとんどコピーして貼り付ける方法で機能を複製する必要がありますか? ... それはおそらく、その機能を移動する正当な理由でもあります。

また興味深い: http://www.martinfowler.com/bliki/AnemicDomainModel.html

于 2009-01-21T22:33:17.123 に答える