Modelクラスのメンバーを操作するメソッドは、 ModelまたはControllerで実装する必要がありますか? この操作がどれほど「重い」かによって異なりますか？
「操作」とは、次のことを意味します。
クラスメンバーを取得する
このクラスメンバーに基づいて長い計算を行います
このクラスに関連する別の値を返す
たとえばBoard class、セル マトリックス メンバーを保持する です。ここで、特定のセルの位置に従って周囲のすべてのセルを返すメソッドを実装したいと考えています。
モデルまたはビューは、上記を実装する責任がありますか?
この質問が別の Stack Exchange QA サイトに属している場合は、投稿をそのサイトに移動するように勧められます。
コントローラーを薄くして、多くのことをさせないでください。これは、オブジェクト指向設計のためのSOLIDの単一責任の原則と一致しています。ファットコントローラーを使用している場合、テストと保守が困難になります。
モデルに関しては、以前はデータベーステーブルにマップするだけで、Webに表示されるほとんどのサンプルアプリケーションに触発されたダムモデルを使用していましたが、現在はそうしていません。
私は（しようと）ドメイン駆動設計の原則に従います。モデル（DDD用語ではエンティティ）がアプリケーションの中心にあり、エンティティに関連する動作をカプセル化することが期待されます。スマートモデルです（つまり、ロジックその場合、オブジェクトに関連するものはそれと一緒に存在します）。DDDははるかに大きなトピックであり、MVCとは直接関係ありませんが、その背後にある原則は、アプリケーションをより適切に設計するのに役立ちます。DDDをグーグルで検索すると、多くの資料とサンプルアプリを利用できます。
さらに、Ruby On Railsコミュニティ（ほとんどのMVCフレームワークに影響を与えているようです）にも、FatModelsとSkinnyControllersの存在について誇大宣伝があるようです。
その上、ビューモデルをミックスに追加できます。これは私が役立つと思います。この場合、ビューを生成するためだけに使用するモデルのダムサブセットを表すViewModelを使用できます。これにより、作業が楽になり、ビューがモデルからさらに分離されて、デザインに影響を与えないようになります。不必要に決定。
あなたが「モデル」と呼んでいるものは、実際にはドメインオブジェクトです。MVC の実際のモデルは単なるレイヤーであり、具体的なものではありません。
特定の例では、Boardこのリストを返すメソッドが必要です。これらの細胞とさらに相互作用を行う必要があるため、実際にそれを取得していると思います。
ここで、モデル層内のサービスが活躍します。それらを使用する場合、それらはモデル層の外側の部分であり、アプリケーション ロジック (異なるドメイン オブジェクト間の相互作用、および永続性 (通常はデータ マッパーまたは作業単位) とドメイン オブジェクト間の相互作用) を含みます。
あなたがゲームを作っていて、あなたとプレイヤーが範囲攻撃を行ったとしましょう。コントローラーは、この機能を担当するサービスを保持し、コマンドを送信します。このプレーヤーは、この方向に AoE を向け、それを実行します。
サービス
Boardは、ターゲットの場所の周囲のセルをインスタンス化し、要求します。次に、取得したコレクション内のすべてのセルに対して「損傷」を実行します。ロジックが完了すると、Unit of Work インスタンスに、 で発生したすべての変更をコミットするように指示しますBoard。
コントローラーは、サービスの詳細を気にしません。また、フィードバックを受け取るべきではありません。実行がビューに到達すると、モデル レイヤーから最新の変更を要求し、UI を変更します。追加の利点として、サービスを使用すると、ビジネス ロジックがプレゼンテーション レイヤー (主にビューとコントローラーで構成されている) でリークするのを防ぐことができます。
ドメイン オブジェクトには、状態を処理するメソッドのみを含める必要があります。
これはMVCとはほとんど関係がなく、通常のソフトウェアエンジニアリングとはもっと関係があると思います。
私は個人的にモデルに些細な計算を固執することを躊躇しませんが、太ったモデルには非常に警戒します。
さて、MVCがModel View Controllerの略であるという事実は、必ずしもすべてがビュー、モデル、またはコントローラーのいずれかである必要があることを意味するわけではありません。M、V、Cのいずれにも該当しない別のクラスに責任を移す必要があると感じた場合、なぜそうすべきでないのかわかりません。
それを実装する方法はあなた次第です。この個別のクラスを「トップレベル」（より適切な用語がないため）オブジェクトとして使用するか、モデルのメソッドをそのクラスに委任して、使用しているという事実を隠すことができます。私はおそらく後者に行きます。
しかし、すべてが議論の余地があります。みんなとその妹は、MVCを正しく行う方法について異なる意見を持っているようです。
私、私はそれをガイドラインと考えています。確かに、それは関心の分離を改善するので素晴らしいアイデアですが、最終的には、いつものように、それを適用するための万能の方法はなく、過度に制約されるべきではありません。 、すべてがビュー、モデル、またはコントローラーのいずれかでなければならないところまで。
ベスト プラクティスに従って、取得アクセスのみで計算フィールドのプロパティを使用する必要があります。例 public double TotalCost { get { return this.Role.Cost * TotalHour; } }