私は最初の実際のASP.NETMVCプロジェクトに取り組んでいますが、作業しているコントローラーがかなり大きくなっていることに気づきました。これは、コントローラーを薄く保つというベストプラクティスに反しているようです。
私はビジネスロジックをコントローラーから遠ざけるのに良い仕事をしました。そのために別のレイヤーを使用します。各アクションは主にビジネスレイヤーのメソッドを呼び出し、modelstateが有効かどうかに基づいて最終結果を調整します。
とはいえ、コントローラーには多数のアクションメソッドがあります。直感的には、コントローラーをサブコントローラーに分割したいのですが、簡単な方法がわかりません。コントローラーを別々のコントローラーに分割することもできますが、階層が失われ、少し汚れた感じがします。
多数のシンアクションでコントローラーをリファクタリングする必要がありますか？もしそうなら、これを行うための最良の方法は何ですか？
まず、コントローラーコードを最小限に抑えるのが良いと聞いた場合、これは主に各アクションメソッドを可能な限り薄くすることを意味します（ビューやViewModelではなくビジネスクラスにロジックを配置します）。 、それは素晴らしいです。
「多すぎる」アクションメソッドを持つことに関しては、これは判断の呼びかけです。それぞれの行動が一つのことに焦点を合わせているということは、実際には良い組織のしるしかもしれません。また、RenderAction専用のアクションを使用している可能性がありますか？そして、コントローラーのテーマに関連してやるべきことがたくさんあるのは、ソリューションの性質かもしれません。
だから、私の推測では、あなたはおそらく大丈夫だと思います。ただし、念のため、メモ用紙でコントローラーを2つまたは3つのコントローラーに分割し、アクションからアクションへとストーリーがどのように機能するかをスケッチします。また、ワークフローがより多くのコントローラーで機能することがわかった場合は、それを分割する必要があります。特に、後でこの機能を追加する場合。あなたのブレークが早いほど良いです。
良い質問。
アナロジーをどのように拡張したいかに応じて、「薄い」コントローラーは「広い」または「高い」必要があると思います。多くのことを行う必要のあるコントローラーを分割するクリーンな方法がない場合、各アクションがビュー/ビューモデルの準備に専念し、コードサイズが制限されている限り、それは問題ではないと思います。
あなたが持っているもう一つの構造的なオプションは、アクションの論理的なグループ化のための部分的なクラスを導入することです。そして、vscommandsのようなものを使用してファイルをグループ化します。
誰かが魔法のような数のアクションを思い付くことができるとは思えません。それは、何かを分割して新しいコントローラーを導入するのが良いアイデアである場合、それは実際にはドメインによって異なります。
別の解決策は、コントローラーに含まれるアクションのビジネスコンセプトに基づいてコントローラーを分離することですが、各アクションのルートはRESTルールに従います。
ただし、このソリューションはファットコントローラーがある場合にのみ使用する方がよいと思います。そうでない場合は、出力リソースに基づいてアクションを分類する方がよいと思います。