MVCに巨大なコントローラー、または多数のコントローラーを配置する方が良いですか？
ASP.NET MVCでかなり大きなHRアプリケーションを構築しており、これまでのところコントローラーは非常に大きくなっています。たとえば、従業員コントローラーがあり、すべての従業員ビュー（個人情報、従業員控除、扶養家族など）が含まれています。これらの各ビューには、複数のアクションまたはサブビュー（CRUDなど）がある場合があります。各アクションは比較的小さいですが、コントローラーには数十の機能がある場合があります。
コントローラを分割するためのベストプラクティスはありますか？数十のビューを持つEmployeeコントローラーを使用する代わりに、サブタイプごとに1つのコントローラー（つまり、EmployeePersonalInfoController、EmployeeDeductionController、EmployeeDependentController）を使用する方がよいでしょうか？
そして最後に、それは重要ですか？
更新された説明
私の当初の懸念はCRUDアクションに関するものでした。たとえば、作成と削除を考えてみましょう...
EmployeeControllerの現在のアクション：
CreateEmployee()
DeleteEmployee()
CreateEmployeeDeduction()
DeleteEmployeeDeduction()
CreateDependent()
DeleteDependent()
etc.
コントローラが分割された場合：
EmployeeController
Create()
Delete()
EmployeeDeductionController
Create()
Delete()
EmployeeDependentController
Create()
Delete()
EmployeeBenefitController
Create()
Delete()
etc.
最初のシナリオでは、最大100台の画面が8〜10台の大型コントローラーに分割されます。 2番目の場合、私はおそらく〜50のコントローラーを持っています。
私の控えめな意見では、コントローラーのコードを停止している場合、それは本当に問題ではありません。
ほとんどのコードは、ビジネスレイヤーのどこかで発生します。その場合は、コントローラーで実際に行っているのは、ビューにデータを返すことだけです。それがあるべきです。
コントローラーをサブタイプに分離するのが好きなのかどうか、本当にわかりません。懸念の分離を維持する必要がありますが、サブタイプは少し行き過ぎだと思います。
この記事を参考にして、効果があるかどうかを確認してください。 同じビューの異なるパス
これは、提案したサブタイプアプローチを使用するよりも優れたソリューションになる場合があります。
部分クラス クラスを複数のファイルに分散できます。このようにして、コントローラーの関連領域を個別のファイルにグループ化できますが、それらはすべて同じコントローラーの一部です。例えば.
EmployeeDeductionController.cs
public partial class EmployeeController
{
public ActionResult Deduct()
{
}
// etc
}
EmployeeBenefitController.cs
public partial class EmployeeController
{
public ActionResult GiveBenefit()
{
}
// etc
}
50台のコントローラーは必要ありません。現在、アプリケーションには16個ありますが、問題はありません。 50のコントローラーがある場合は、ビュー用の50のトップレベルフォルダーもあります。作業する必要のあるビューとコントローラーを見つけるのは難しいでしょう。他の人が言及したように、アクションは通常短いものであり、それらをコントローラーにいくつか持つことはそれほど悪くありません。
システムパーツごとにコントローラーを1つ持つようにしました。私はデータベーススキーマを取得し、一緒に属するテーブルの周りに線を引くことによって、システムパーツを定義します。
それらをグループ化しないのはなぜですか？
次のような構造にしてください
employee/payroll/
employee/payroll/giveraise
employee/payroll/manage401k
employee/general/
employee/general/address
employee/general/emergencycontact
これで、給与関連のアクションを処理する1つの給与コントローラと、従業員の定期的な詳細を処理する汎用コントローラを使用できます。
私たちが使用しているもう1つのアプローチは、CRUD操作の一般的な場所で横断的な懸念を維持するControllerBaseを使用することです。このコントローラーは、一般的な操作を宣言し、特定のエンティティーの拡張ポイントを含みます。このようなものがなければ、コードの重複が多すぎました。
次に、このコントローラーを継承し、エンティティごとに1つ作成します。そして、はい、多くのコントローラーがありますが、画面が非常に多いので、それが主な問題になるとは思いません。
ほとんどのアクションは複雑なモデルを受け入れ、モデルバインダーを使用してコントローラーから混乱を取り除きます。あなたはそれについての良い投稿を見ることができます here 。
次に、@ Oddが示唆するような領域を使用することは、少なくともビューを分離することをお勧めします。
ASP.NET MVC v2が領域とカプセル化ビューをさまざまなアセンブリにもたらすことを期待しています（実際には、VirtualPathProviderクラスを拡張することで実現できます）。
コントローラは、1つのコンテキストでのアクションのコンテナになることを意図しています。 I.E.カスタマーコントローラーには、カスタマーの制御に関連するアクションがあります。これは特にCRUDに適しています。このため、私はより大きなコントローラーを少なくするつもりです。とはいえ、コードに最も適した方法を選択するのはアプリケーションアーキテクトであり、1つの方法で行う方が一般的だからといって、必ずしもそうする必要はありません。
大量のコードがある場合は、ASP.NET MVC領域を調べることをお勧めします。あなたはそれについてのすばらしい投稿を見つけることができます ここスコット・グのブログで そして ここスティーブ・サンダーソンのブログで 。非常に多くのコントローラーがある場合、それはあなたに適しているかもしれません。
あなたの投稿をもう一度読んだ後、考えただけで、あなたの例があなたのコードにある複雑さのレベルに近づかないのではないかと思います。おそらく、より具体的な（そしてCRUDはかなり単純なので、CRUDDYが少ない）コントローラーを分割することが良いアイデアであるかどうかわからない状況を投稿した場合に役立つかもしれません。
ユースケースとその論理グループを大まかにコントローラーを整理します。例えば。限られたグループの人々が利用できる可能性が高い管理/ HRタイプのユースケースが複数ある場合は、それらを1つのコントローラーにバンドルします。その他のコントローラーは、特定のドメインモデルオブジェクト（たとえば、セルフサービスの休暇管理、給与クエリなど。厳格なルールはありません。単一のコントローラーにあまり責任を負わないことと、一般的な内部構造の再利用とのバランスをとる必要があります。
また、コントローラーにコアビジネスロジックを含めないでください。実際のシステムルールはドメインモデルとサービスレイヤーにある必要がありますが、実際にはフロントエンドの動作を実装しています。ほぼ適切なレイヤー内に物事を保ち、合理的に分離されている限り、個々の操作をコントローラー内にどのように配置するかについて、それほど問題はありません。