[解決済み] 太ったモデルと痩せたコントローラーは、まるで神モデルを作っているようだ。

モデル層が構成する主なパーツは、以下の通りです。

• ドメインオブジェクト

  ドメインエンティティ、ビジネスオブジェクト、またはモデルオブジェクトとしても知られています (後者の名前は混乱を招くだけなので、私は好きではありません)。これらの構造は、人々が通常誤ってモデル (models") と呼ぶものです。これらはビジネスルール（ドメインロジックの特定のユニットのすべての計算と検証）を含む責任があります。

• ストレージの抽象化です。

  通常 データマッパー パターンで実装されています。 ORMs と混同しないでください）。これらのインスタンスは通常、ドメインオブジェクトからの情報の保存と、ドメインオブジェクトへの情報の取り出しを任務とします。各ドメインオブジェクトは複数のマッパーを持つことができ、ちょうどストレージの形態（DB、キャッシュ、セッション、クッキー、/dev/null）がいくつかあるようなものです。

• サービスです。

  アプリケーションロジック（つまり、ドメインオブジェクト間の相互作用、ドメインオブジェクトとストレージ抽象化間の相互作用）を担当する構造体です。これらはプレゼンテーション層がモデル層と相互作用するためのインターフェイスのように動作します。これは通常、Railsのようなコードではコントローラの中で終わるものです。

また、これらのグループの間のスペースに入るかもしれない構造物がいくつかあります。 DAOs , 作業単位 および リポジトリ .

_{ああ......そして、私たちが (ウェブの文脈で) ユーザー について話すとき、それは人間ではありません。ユーザーとは、実際には Web ブラウザのことです。}

では、神々についてはどうでしょうか？

恐ろしくてモノリシックなモデルを扱う代わりに、コントローラはサービスと相互作用する必要があります。ユーザーの入力したデータを特定のサービス (例えば MailService または RecognitionService ). この方法では、コントローラはモデル層の状態を変更しますが、それは明確なAPIを使用し、内部構造をいじらずに行われます（これは抽象化の漏れを引き起こします）。

このような変更は、即座に何らかの反応を引き起こすか、ビューインスタンスがモデル層から要求するデータにのみ影響を与えるか、あるいはその両方が考えられます。

各サービスはドメインオブジェクトとストレージの抽象化された任意の数(通常はほんの一握りですが)と相互作用することができます。例えば RecogitionService は記事のためのストレージの抽象化について気にかけることはできません。

終了時の注意

このようにして、どのレベルでもユニットテストが可能で、（正しく実装されていれば）カップリングが低く、明確に理解できるアーキテクチャを持つアプリケーションを得ることができるのです。

しかし、心に留めておいてください。MVC は小さなアプリケーションのためにあるのではありません。もしあなたがMVCパターンを使ってゲストブックのページを書いているとしたら、それは間違ったやり方です。このパターンは 法律と秩序 を強制するためのものです。

_{PHPを主要な言語として使っている人のために。 この記事 が適切かもしれません。モデル層についてのもう少し長い説明と、いくつかのコードの断片があります。}