私は特に、ファットモデルと細いコントローラーのアプローチを支持する多くのブログを読んでいます。Railsキャンプ。その結果、ルーターは基本的に、どのコントローラーでどのメソッドを呼び出すかを理解しているだけであり、すべてのコントローラーメソッドは、モデルの対応するメソッドを呼び出してビューを表示します。だから私はここで私が理解できない2つの懸念を持っています：
どこに線を引くのですか？これは単に神のパターンに該当するのではないですか？
回答:
RailsをMVC設計パターンの定番として見るのは、最良のアイデアではないかもしれません。このフレームワークは、いくつかの固有の欠点（別の投稿で少し詳しく説明しました）で作成され、コミュニティはたった今、放射性降下物への取り組みを開始しました。DataMapper2 開発を最初の主要なステップとして見ることができます。
そのアドバイスをする人々は、非常に一般的な誤解に悩まされているようです。だから、それを片付けることから始めましょう：モデルは、現代のMVC設計パターンでは、クラスでもオブジェクトでもありません。モデルはレイヤーです。
MVCパターンの背後にある中心的なアイデアは、懸念の分離であり、その最初のステップは、プレゼンテーションレイヤーとモデルレイヤーの分割です。プレゼンテーションレイヤーがコントローラー（ユーザー入力の処理を担当するインスタンス）、ビュー（インスタンス、UIロジックを担当）、およびテンプレート/レイアウトに分解されるように、モデルレイヤーもそうです。
モデルレイヤーを構成する主要な部分は次のとおりです。
ドメインエンティティ、ビジネスオブジェクト、またはモデルオブジェクトとも呼ばれます（混乱を招くため、後者の名前は嫌いです）。これらの構造は、人々が通常誤って「モデル」と呼ぶものです。彼らは、ビジネスルール（ドメインロジックの特定のユニットに対するすべての計算と検証）を含める責任があります。
ストレージの抽象化：
通常、データマッパーパターンを使用して実装されます（この名前を乱用したORMと混同しないでください）。これらのインスタンスは通常、ドメインオブジェクトからの情報の取得とドメインオブジェクトへの取得を担当します。ストレージのいくつかの形式（DB、キャッシュ、セッション、Cookie、/ dev / null）があるように、各ドメインオブジェクトは複数のマッパーを持つことができます。
サービス：
アプリケーションロジック（つまり、ドメインオブジェクト間の相互作用、およびドメインオブジェクトとストレージアブストラクション間の相互作用）を担当する構造。それらは、プレゼンテーション層がモデル層と相互作用するための「インターフェース」のように機能する必要があります。これは通常、Railsのようなコードでは、最終的にコントローラーになります。
これらのグループ間のスペースには、DAO、作業単位、リポジトリなどの構造もいくつかあります。
ああ...そして、MVCアプリケーションと対話するユーザーについて（Webのコンテキストで）話すとき、それは人間ではありません。「ユーザー」は実際にはあなたのウェブブラウザです。
怖いモノリシックモデルを使用する代わりに、コントローラーはサービスと対話する必要があります。ユーザー入力から特定のサービス（MailServiceまたはなどRecognitionService）にデータを渡します。このようにして、コントローラーはモデルレイヤーの状態を変更しますが、これは明確なAPIを使用して行われ、内部構造を変更することなく行われます（これにより、抽象化がリークします）。
このような変更は、即座に何らかの反応を引き起こすか、ビューインスタンスがモデルレイヤーから要求するデータのみに影響を与えるか、またはその両方になります。
各サービスは、任意の数のドメインオブジェクトとストレージアブストラクション（通常はほんの一握りです）と対話できます。たとえばRecogitionService、は記事のストレージの抽象化についてあまり気にすることができませんでした。
このようにして、任意のレベルで単体テストを実行でき、カップリングが低く（正しく実装されている場合）、アーキテクチャが明確に理解できるアプリケーションを取得できます。
ただし、MVCは小規模なアプリケーション向けではありません。MVCパターンを使用してゲストブックのページを作成している場合、それは間違っています。このパターンは、大規模なアプリケーションに法と秩序を適用するためのものです。
PHPを第一言語として使用している人にとっては、この投稿が関連するかもしれません。これは、いくつかのコードスニペットを含むモデルレイヤーの少し長い説明です。
「モデル」クラスが十分に実装されていない場合は、懸念事項が関係しています。モデルクラスは、電子メール（インフラストラクチャタスク）を実行するべきではありません。
本当の問題は、MVCのモデルが何を意味するかです。いくつかのメソッドを持つPOCOクラスに限定されていません。MVCのモデルとは、データおよびビジネスロジックを意味します。古典的なコアPOCOモデルのスーパーセットとして扱います。
ビュー====コントローラー====モデル--->ビジネスプロセスレイヤー->コアモデル
インフラストラクチャアセンブリとデータアクセスレイヤーを投入し、インジェクションを使用してそれをBPLに渡すと、プロセスは意図したとおりにMVCを使用します。
BPLはUoW /リポジトリパターンを呼び出し、ビジネスルールを実行し、注入されたオブジェクトまたはインターフェースパターンを介してインフラストラクチャ機能を呼び出すことができます。
したがって、コントローラーを細くするという推奨事項は、クラシックCoreモデルの「人物」クラスに50のメソッドがあり、Emailを直接呼び出す必要があることを意味しません。これは間違っていると考えるのは当然です。
コントローラは、直接呼び出された場合、インフラストラクチャクラスをインスタンス化してBPLまたはコアレイヤに注入する必要があります。ビジネス層、または少なくともクラシックオブジェクトモデルクラス全体で呼び出しを調整するクラスが必要です。とにかくそれは私の「ビュー」です;-)
MVCの一般的な見方については、wikiの説明http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
MVCの「M」について語る小さなブログ。http://www.thedeveloperday.com/skinny-controllers/
単一のファットモデル（名前はAppまたはApplication）と、論理グループ（ビジネス、顧客、注文、メッセージ）に分割されたいくつかのファットモデルを区別できると思います。後者は私がアプリを構成する方法であり、各モデルは、リレーショナルデータベースのデータベーステーブルまたはドキュメントデータベースのコレクションにほぼ対応しています。これらのモデルは、データベースと通信する場合でも、APIを呼び出す場合でも、モデルを構成するデータの作成、更新、および操作のすべての側面を処理します。コントローラは、適切なモデルを呼び出してテンプレートを選択するというほとんどの原因となる非常に薄いものです。