6

1) あなたのウェブサイトのホームページは「コントローラー」のどこに当てはまりますか? about、home、contact などの静的ページを処理するために「ページ」コントローラを使用している人を見てきましたが、これは良い考えではないように思えます。ホームページ専用に別のコントローラーを作成する方が良い選択肢でしょうか? 結局のところ、複数のモデルにアクセスする必要があるかもしれませんし、一部の人々が使用するモデル理論ごとに 1 つのコントローラーというように、全体ではうまく流れません。

2) 複数のタイプのユーザー用のダッシュボードが必要な場合、それは、ユーザーに依存するトグル コードを持つ 1 つのダッシュボード コントローラーでしょうか。それとも、ユーザーごとに各コントローラー内のダッシュボード アクションを言うでしょうか? たとえば、管理者/ダッシュボード、アカウント/ダッシュボードなどです。

3) コントローラを説明しようとするとき、単純な CRUD の例全体を使用することは魅力のように機能しますが、それらの単純な機能を過ぎてしまうと、それは故障し、コントローラが扱いにくくなる可能性があるように思えます。ユーザーコントローラーでログイン機能を作成する人がいるのに、ログインコントローラーを作成することを選択する人がいるのはなぜですか? 私が思う理由の 1 つは、私たちの多くがページ アプローチのバックグラウンドを持っており、ページが常にそのように機能するとは限らないため、コントローラーを「オブジェクト」または「名詞」と考えるのが難しいためです。アクションを収める「コンテナ」を持つためだけに、実際には互いに何の関係もないページを処理する「ページ」コントローラを作成する必要があるのはなぜでしょうか。私には正しくないようです。

4) コントローラーは、アクションを実行できる「オブジェクト」よりも、ユースケースに関係する必要がありますか? すべての集中的な目的のために、アプリ全体ですべてのアクションを実行するユーザー コントローラーを作成できます。または、一部の人が言うように、「関心のある領域」ごとにコントローラーを作成することもできます。または、必要に応じて、ビューごとに 1 つのコントローラーを作成することもできます。あまりにも自由度が高いため、一貫した方法を使用するのが難しくなっています。

コントローラーはおそらくこれほど混乱しないはずですが、何らかの理由で私を困惑させてしまいます。有益なコメントをいただければ幸いです。

4

1 に答える 1