ウィキペディアでは、単一責任の原則について次のように説明しています。
単一責任の原則は、すべてのオブジェクトが単一の責任を持つべきであり、その責任はクラスによって完全にカプセル化されるべきであると述べています。そのすべてのサービスは、その責任と密接に連携する必要があります。
MVC でのコントローラーの従来の使用法は、プログラマーをこの原則に違反する方向に導くようです。シンプルなゲスト ブック コントローラーとビューを使用します。コントローラーには、1) Index() と 2) Submit() の 2 つのメソッド/アクションがある場合があります。Index() はフォームを表示します。Submit() がそれを処理します。これらの 2 つの方法は、2 つの異なる責任を表していますか? もしそうなら、単一の責任はどのように作用しますか?
はい、そうです。
また、SRP に従いたい場合は、コントローラーをディスパッチャーとアクションに分解します。Dispatcher はコントロールをそのアクションにディスパッチし、コンパイル時 (C++ テンプレート) または実行時 (Java XML など) に Dispatcher と Action を作成します。
これをもっと頻繁に見ませんか？コントローラーは多くの場合、「アドホック」な実装であり、一般化されておらず、サブクラス化されることを意図していないリーフレベルの具象クラスであるためです。ここでは、クラスはコードを便利にグループ化するために使用されます。アクションはほぼ確実に非公開 (おそらく非公開、おそらく保護) であり、「単なる」内部実装の詳細です。
どのアクションにディスパッチするかを決定する方法の選択肢、可能なアクションの数と多様性は高く、ディスパッチとアクションは密接に結びついています。したがって、実際には、コードを 1 か所にまとめた方が簡単なことがよくあります。
いいえ、そうではありません。
MVC パターンまたはそのバリエーションに固有のもので、単一責任の原則に違反するものは何もありません。コントローラの実装が SRP に違反しているかどうかは、カプセル化された動作に (他のクラスと同様に) 複数の変更理由があるかどうかに基づいており、パターンの規範的な使用が前提とされているためではありません。
あなたが示した例は、データアプリケーションを介した基本的なフォームのサブセットであり、コントローラーは特定のモデルに CRUD 操作を提供するだけです。CRUD 操作は本質的にかなりまとまりがあるため、通常、これは SRP の違反にはなりません。単一のコントローラーに複数のメソッドがあることが疑われ始めるのは、メソッドがドメイン全体で異なる動作の相互作用を表している場合です。
とはいえ、CRUD が 4 つの個別の非凝集性の問題を表していると主張する人がいたとしても、同じコントローラー内でこれらの各アクションを容易にすることを強制する MVC パターンに固有のものは何もありません。
MVC パターンの歴史と、Web 開発におけるそのアプリケーションの説明については、Interactive Application Architecture Patternsを参照してください。