ASP.NET MVC:コントローラーの構築

Question

それで私は次のことに着手しています ASP.NET MVC 全体的には良い経験でしたが、コントローラーがスパゲッティ状になったことにはあまり満足していません。オンラインで調べてみたところ（CodeCampServerなど...）、それらはすべて、コントローラーメソッドがかなり一貫してSRP（単一責任原則）に違反するという同じ問題に悩まされているようです。たとえば、リクエストが次の場合に単にビューをレンダリングするコントローラーメソッドなどです。ある GET しかし、更新します model それが POST. 。これで、アプリケーション全体の複数の論理ルートを担当するコントローラー メソッドができました。たとえば、どの論理ルートをチェックするかです。 button フォームをクリックすると、それに応じて動作します。JavaScript を使用して各ボタンのクリックを別のフォーム アクションにリダイレクトすることはできますが、そこにも何か違和感があります...もう一つの大きな問題は魔法の蔓延です strings - ViewData["foo"] = blah; 簡単に言うと、皆さんはどうですか structure あなたの controller 論理？ビューごとに 1 つの巨大なモデル オブジェクトですか?たくさんの小さな controller methods そして JavaScript ルーターですか？私の目標は保守可能なコードです。機能が積み重なるにつれて、滑りやすい坂を滑り落ち始めています...

Answer 1

ASP.NET プレビュー 5 (以下で利用可能) コードプレックス）これに対する答えは次のとおりです。[AcceptVerbs] 属性。フィル・ハークは ブログ投稿 それがどのように使われるかを議論します。

ビューデータのマジックキーの質問に関しては、興味深い問題です。ビューを半独立したコンポーネントの束として考える場合 (特に新しい部分ビューのサポートを考慮すると)、ビューのいくつかの部分は比較的独立している必要があるため、強く型付けされたモデルを作成することは理想的ではなくなります。お互いに。

Answer 2

さまざまな人々がこの問題をどのように扱っているのでしょうか?モデル フォルダー内のごちゃごちゃした内容を確認するのに数時間を費やしただけだと思います。フォルダーを作成すると、視覚的な煩雑さを軽減するのに役立ちますが、一致する名前空間を使用することも非常に役立ちます。

しかし、私のコントローラーは現時点ではモノリスです。問題は、私がプロジェクトのこの時点まで学習に集中してきているということです (まだ整理すべき点がたくさんあります)。

MVC を十分に理解できるようになったので、複雑さを見直し、より適切な名前が付けられた、よりクリーンな関数にコントローラーを変更することを検討します。

他の人はコントローラーをサブコントローラーに分割していますか?(そんな事があれば)