OrderItemDepartments：それぞれが有するCRUDアクション例えば：ネットコア休憩APIベストプラクティス
OrderItemDepartmentsController
。
OrderItemSectionsController
OrderItemsController
..Orルーティングを介してのOrderItems、部門やセクションにサービスを提供する単一のコントローラを有する：
OrderItemsController
私はすべてのケースをカバーします。このため、単一の明確な答えはあります疑うが、一般的に、それは良いことですアイデアは自分のクラス内でアプリケーションの各特定の部分に対する責任をカプセル化するアイデアです。
あなたが言及CRUD（C reate、R EAD、U pdate、D elete）、そのここで中心点です。名前がわかるように、これらの操作は通常、特定のパターンに従います。 contoller-classをすべて同様の方法で整理できれば、ヘルパークラスや各コントローラが実装できるインターフェイスに共通ロジックを抽出することができます。これにより、後でアプリケーションを展開する必要がある場合は、アプリケーションの柔軟性が向上し、問題が少なくなります。
アプリのトップレベルで別のコントローラを使用することで、下位レベルのコンポーネントを簡単に整理できるようになります。たとえば、各コントローラに対応した別々のビジネスコンポーネントやリポジトリコンポーネントを持つことができますが、これらのコンポーネントのそれぞれは共通のインタフェースを実装できます。そうすることで、アプリケーションの各部分は、内部的に一貫した別個の「垂直スライス」（コントローラ、ビジネス、リポジトリなど）で構成されます。
アプリケーションに新しい機能を追加する必要がある場合は、理解しやすい明確なパターンがあり、開発をスピードアップすることができます。既存のインターフェイスと同じ共通インターフェイスを実装し、ビジネス・レイヤーとリポジトリー・レイヤーの新しいコンポーネントでも同じです。
私は神のコントローラを避けるべきだと思います。神のコントローラ/クラスなどは決して良い考えではありません。むしろ、あなたは、単一責任原理にスティックし、それが属する場所に機能を広げるべきです。これにより、非常に直感的で簡単なRESTfulルーティングが可能になります。 – krzysztofla
私は@KrzysztofLaに同意します。あなたは、あなたのAPI構造に関して、懸念を明確に分離したいと思っています。 1人のコントローラーにすべての（または神のコントローラー）を支配させることで、後で開発に噛まれるようになります。非常に特定のコントローラーメソッドから可能な限り少ないデータ量を返すと、ユーザーの心配があります。 –