私は一般に、論理グループごとに1つのコントローラを持っています。しばしば、これはモデルごとに1つのコントローラに対応することがあります。
カテゴリーのリストを表示する簡単なオンラインカタログを作成し、ユーザーがカテゴリーを選択したときにカテゴリーと製品に対する操作の管理パネルと一緒にそのカテゴリーのプロダクトのリストを表示するとします。私は2つのモデル(CategoryModel
とProductModel
)を持っています。フロントエンドのカテゴリリストを作成したコントローラと、商品リストを生成した別のコントローラ(たとえば、CategoryController
とProductController
)があります。私はその後、バックエンド(AdminCategoryController
とAdminProductController
)のカテゴリと製品のコントローラを持っています。 2つのバックエンドコントローラは、それぞれのモデルのリスト/追加/編集/削除/表示操作を処理します。あなたのURL構造を考えて、関連する機能を関連するURLに入れると、あなたのコントローラー構造はしばしばあなたのURL構造と一致します。実際、いくつかのフレームワーク(例えば、CodeIgniter)はデフォルトの動作としてコントローラの名前に基づいてリクエストをルーティングします。
コントローラーの内容は、モデルがデータアクセス用で、データベース構造をラップして非表示にするという考え方で動作します。 "ステータスが '完了'に設定されているときにcompletion_dateに現在の時間を割り当てるなどのロジックは、最適なモデルです。
ビューにはプレゼンテーション全体が含まれます。コントローラ/モデルは、HTMLを生成したり、処理したりしてはいけません。 2列または3などの決定はビューに属します。ビューのロジックは、可視出力を生成するために必要なものに制限する必要があります。ビューからデータベースを照会したい場合は、おそらくビューに多すぎるロジックを置いているでしょう。
コントローラは残っているもの用です。一般に、入力を検証し、モデルにフォームデータを割り当て、適切なビューを選択し、要求を処理するために必要なモデルをインスタンス化することを意味します。
ありがとうございました。これは私がやっていることです。 私がしようとしていることの1つは、モデルレイヤーにロジックを追加することです。私はpropelモデルオブジェクトを使用しており、バリデーションがモデルレイヤーに入るべきだと考えていました。コントローラーはモデル内のデータを設定するだけです... – AndreLiem
一部の開発者は、すべての検証をモデルに入れたいと考えています。私はフォームの検証がコントローラでよりよく行われることを知り(UIに密接に結合されているため)、基本データ型の検証(例:列挙型フィールドを特定の値に制限する)はモデルでうまく機能します。 –