コントローラーに多数のアクションが含まれていると、コントローラーが大きくなり扱いにくくなる可能性があります。これは実際の使用において重大な問題ですか? もしそうなら、それを軽減するための戦略は何ですか?
頭のてっぺんから、コントローラーがロジックを他のタイプのアクション実装にオフロードし、意味のあるヒューリスティックに従ってグループ化することを想像できます。
1 に答える
3
私の経験では、これはほとんどの場合、「REST」ナイフを十分に積極的に適用しない場合に発生します。比喩は、問題についての私たちの考え方と一致しない場合があります。たとえば、「ログイン」は「アカウント」に対するアクションだと考えがちですが、REST ナイフを適用すると、ログインが実際には「新しいセッションを開始する」ことであることに気付き、「新しいセッションを開始する」ことで発想を逆転させます。 " (または Create) アクションを SessionController に追加します。次に、セッションの作成と破棄 (ログインとログアウト) を担当する小さなコントローラーがあります。
認証という厄介な概念で REST の世界を混乱させるのを好まない人もいると思います。そのため、より明白な例を見てみましょう。私は BlogPost エンティティを持つことができ、それはたくさんのコメントを持つことができます。BlogPostController にアクション AddComment を用意するのではなく、BlogPost に通常の作成/編集/削除メソッドを用意し、新しい/作成アクションが BlogPostId を想定し、作成/編集/削除メソッドを実装する別のコントローラー CommentController を用意しています。
「CSVファイルからXのリストをインポートする」など、RESTに似ていないアクションが必要な状況に遭遇しました。それぞれがYに属しています。「リスト」は、ドメインの概念としてはそれほど重要ではありません。実際には、既存の Xes のコレクションに追加しようとしているだけだからです。その場合、XController に「インポート」アクションを追加するという、やや醜いアプローチと思われる方法を採用しました。そのコードは、私のコントローラーの中で最も厄介なコードであり、責任をより限定されたもの (おそらく XImporter クラス) に分解したいと思いますが、今のところ「機能します」。私よりも賢い人なら、もっと良い解決策があるはずです。
したがって、私の主張は次のとおりです。RESTy 以外のアクションがたくさんある場合は、一種のコードの匂いがします。正しく制御しているものをモデル化していない可能性があります。しかし、1 ～ 3 回の unRESTy アクションと問題の再考の試みが正しい方向に導かないと言うなら、おそらく心配する価値はありません。
于 2010-01-15T18:45:12.473 に答える