MVCアーキテクチャ-コントローラーはいくつ必要ですか？
私はしばらくコーディングしてきましたが、ほとんどはスクリプトと単純なアプリケーションです。私はWebアプリケーションの開発と適切なMVCアーキテクチャの使用に関するすべての新しい役割に移ったので、私は必死にそれらすべてを非常に迅速に学習しようとしています。
この質問が「 MVCアーキテクチャのベストプラクティス 」にあまり似ていないことを願っていますが、いくつかの異なるチュートリアルを行っていると、いくつかの異なるコントローラが複数あることに気付きました。
1つのWebアプリにいくつのコントローラーが必要ですか？
これは例がないと答えるのが難しいので、私はそれを提供します：
応用：
- ユーザーがログインします。
- ユーザーは次の3つのいずれかを実行できます。
a）ファイルをアップロードします（メタデータとともにmongodbデータベースに保存されます）。
b）ファイルを検索します。
c）ログアウトします。
私の質問は一般的な質問ですが、答えようとする人を助けるために例を挙げました。
あなたの例では、2つのコントローラーを作成します。
- ログインとログアウトのセッションコントローラ（RESTレイアウトのセッションを作成および破棄）
- ファイルに関するすべてのファイルコントローラ（index = searchおよびcreate = upload）
一般に、すべてを表示、作成、編集、破棄できるリソースと考えるRESTfulなアプローチは、物事を構造化する方法を理解するのに役立ちます。私の例からわかるように、RESTのすべての動詞にあまり近づきすぎていません。
ほとんどの場合、追加の機能を使用するにはさらに多くのコントローラーが必要になります。たとえば、ユーザーが新しいアカウントを作成できるユーザーコントローラです。これに加えて、より高い権限でリソースを編集できる管理インターフェイスが必要になります。このような場合、ほとんどすべてのコントローラーを複製するのが一般的です。
初期のアイデアを得るための非常に大まかな見積もりは、ユーザーがアクセスできるデータベース内のすべてのテーブルに対して1つのコントローラーになる可能性があります。しかし、これは実際には非常に大まかな測定にすぎません。
それは本当にウェブアプリに依存します。あなたの例では、おそらく1つで十分です。送料、税金、在庫管理、段階的な価格設定などを備えた本格的なeコマースアプリを実装する場合は、さらに2つ以上使用することをお勧めします。
コントローラーが1つ以上の コードのにおい （特に ラージクラスまたは神のオブジェクト ）に苦しんでいる場合、おそらく1つだけを実行する時点を過ぎていることがわかります。
それは本当にアプリケーションのニーズとビジネスモジュールのアーキテクチャに依存します。
一般的な経験則、必要なコントローラーの数は、Webアプリ内のモジュールとサブモジュールの数によって異なります。
補足として、コントローラーをAreasに編成すると役立ちます。 Areas の概念はASP.NET MVCフレームワークに組み込まれており、1つのモジュールを提供するコントローラーの構成を簡素化します。
いくつかの関連する議論があります：
Appleのやり方が好きだ。
すべてのビューは、1つのView Controllerのみによって制御されます。 〜 iOS向けView Controllerプログラミングガイド
考え方は、ビューを簡単に交換できるようにする必要があるということです。 IMO、ControllerごとにViewを1つだけ持つことで、これを簡単に実現できます。しかし、複数のビューを持つコントローラーがあり、それでもプログラムロジックを変更せずにビューを切り替えることができるように設計することができると私は確信しています。
私が好きな1つの例は、サーモスタットのことです。サーモスタットは、MVCパターンを表示するのに最適なビジュアルです。
古いアナログサーモスタットでは、次のように想像できます：
表示-現在の温度を表示する温度リーダー。
Controller-温度を変更するダイヤル
モデル-温度を変化させるコントローラーによって呼び出される内部のパーツ。
疎結合を可能にし、モデルとそれに関連するコントローラーを単一のタスクに制限する設計を常に遵守する必要があります、そして必要な数のモジュール/コントローラーを使用する必要があります。アプリケーションのサイズによっては、モデルやコントローラーよりもビューがはるかに少ない場合があります。これは、大きなサイズのアプリケーションで予想されることです。優れたオブジェクト指向プログラミングは、疎結合、カプセル化、継承、および多態性を特徴としています。すべての言語が多態性を同程度にサポートしているわけではありません（関数、メソッド、演算子のオーバーロード/オーバーライド）。
MVCアーキテクチャの適切な使用についてより深く理解したい場合は、コード例としてC++とSmalltalkを使用するGoF「設計パターン：再利用可能な要素のソフトウェア」を参照してください。この本はアルファでもオメガでもありませんが、それは確かに始まりです！
幸運を！
あなたの例は複雑なシステムに進化すると思います。
応用：
ユーザーがログインします：
LoginController
その唯一の責任は、ログインの処理、リダイレクト、またはユーザーへの結果の通知です。
ファイルをアップロード
UploadController
ここでは、あらゆるタイプのファイルをアップロードすることを想定しています。後でMP3やPDFをアップロードすることにした場合は、ベースのUploadController、MP3UploadController、PDFUploadControllerを用意します。
ファイルを検索します。
SearchFileController
これは基本的な要件には十分です。検索ロジックがどれだけ複雑になるかに応じて、後日複数の検索コントローラーを使用できます。最後に必要なのは、さまざまな検索を実行する20のアクションメソッドを持つ単一のSearchControllerです。
ログアウト。
-LogoutController。
これはやり過ぎだと思うかもしれませんが、そうは思いません。私はそれがきれいできれいに分離されていると思います。
このプロジェクトの構造を見ると、その機能と構造をすぐに理解できます。さらに一歩進めるために、LoginControllerとLogoutControllerを別々の領域に配置します。
私は以前にこのようなものを開発し、それは本当にうまくいきました。
ほとんどのコードはビジネス層で発生しますよね？その場合は、コントローラーで実際に行っているのは、ビューにデータを返すことだけです。
コントローラーをサブタイプに分離するのが好きなのかどうか、本当にわかりません。懸念の分離を維持する必要がありますが、サブタイプは少し行き過ぎだと思います。また、重いオブジェクトがコンストラクタまたはコントローラで初期化される場合にも注意する必要があります。例：この例では、ユーザーがログインページにいるときに検索/アップロードファイルにのみ使用される重いオブジェクトが必要になります。
ロジックユニットごとにコントローラーを用意することをお勧めします。たとえば、AccountController（ログイン、登録、ログアウト）、FileController（検索、アップロード）などです。
一般に、すべてのモデルには独自のコントローラーと専用のビューがあると言えます。一般的に言って、これがベストプラクティスであることを意味します。
アプリケーションアスペクト（ユーザー管理など）はアプリケーションサービスに変換する必要があり、コントローラー自体から呼び出すか、コントローラーをラップする必要があります（例えば、コントローラーの機能を要求ユーザーの役割に応じて「可視」にする属性を使用）。
すべてのコントローラーは基本的にモデルに対するCRUD操作を処理し、フィルターごとに異なるビューを使用する必要があることに注意してください。
私の意見では、パターンとしてのMVCの主な利点の1つは、モデルとビューを結び付ける最善の方法を提供することです。
追加した例について：2つのコントローラーを作成します。1つはすべてのユーザーのログイン操作（登録、ログイン、ログアウトなど）用で、もう1つはファイル操作（アップロードと検索）用です。最初のものは、ログイン機能に関連するいくつかの側面でバックアップする必要があり、2番目は通常のコントローラーであることに注意してください。