これをグーグルで検索しようとしましたが、一度だけ答えが欲しいです。
ビジネス ロジックをモデルに入れることができるかどうかについて、社内で議論しています。
たとえば、ID がデータベースで int に設定されていることを確認したい場合。intval($id)それでは、モデルクラスでできますか？またはテキスト入力が短すぎる場合。または、コントローラーで「する必要があります」ですか？
正しい方法はどれですか？
私にとっては、計算など、モデルに必要のないもの (非常にクリーンである必要があります) は、コントローラーにある必要があります。
重複の可能性があり申し訳ありません。
太ったモデル、細身のコントローラー。
コントローラーで関連するセッターを呼び出す複数の場所ではなく、1 つの場所でのみキャストを行うため、モデルでキャストを行うことは問題ありません。10 個の異なるコントローラーでセッターを 10 回使用した場合、10 個の異なる場所で変数をキャストしていることを確認する必要があります。
にキャストする場所を心配する必要はありませんint。明らかに MVC について非常に間違った理解を持っているのではないかと心配してください (残念ながら、多くの人がそうしています)。モデルがすべてです。モデルはアプリケーションをモデル化します。モデルは、アプリケーションの機能を表す自己完結型のブロックです。
コントローラーは、モデルに何かを実行させるための単なる手段です。これは、外の世界と「アプリケーション」の間の接着剤です。コントローラーはリクエストを受け取り、そのリクエストに基づいてモデルが何をすべきかを決定します。ビューは、何が起こったのかを視覚化するか、ユーザーにモデルの状態についての洞察を与えるように求められます。
私は通常、次の観点から構造を考えます。
モデルは最大のチャンクです。プリミティブは、アプリケーション内の 1 つのもの(ユーザー オブジェクト、投稿オブジェクト)を表す個々のオブジェクト (クラス)です。services、あなたができることです（「ユーザーを登録する」、「投稿を作成する」）; storage/databaseは、データベースからのプリミティブの格納/取得を管理します。それらがどのように連携し、どのように正確に名前を付けるかはアプリによって異なりますが、これらは通常、対処する必要がある概念的な部分です。
ビューは、テンプレートを含む場合と含まない場合がある独自のレイヤーです。
ご覧のとおり、これがアプリケーションが実行する必要がある作業のほとんどであり、コントローラーはアプリケーションの最小部分です。コントローラーは主に入力を受け取り、モデル サービスを呼び出し、応答としてどのビューをレンダリングする必要があるかを示します。
この分離が理にかなっている理由を視覚化するには、アプリケーションをどのように使用するかを自問してください。ユーザーが何かを実行できる Web サイトを持つことは一般的です。しかし、JSON API インターフェースも必要になるのではないでしょうか? それとも、管理タスク用のコマンド ライン クライアントですか? これらのシナリオは両方とも、異なる入力処理と異なる出力を必要とするだけです。ただし、「ユーザーの登録」と「投稿の作成」は、呼び出し方に関係なく同じアクションです。したがって、それらはモデルに属します。JSON API または CLI ツールを作成するために必要なのは、わずかに異なるコントローラーとビューだけです。このすべてにおいて、コントローラーは実際には最小の部分であり、ビジネス ロジックを含めることはできません。