管理領域の名前空間は、これらのコントローラーをパブリック/ユーザー向けコントローラーから分離するため、良い考えです。ここでの大きな利点はセキュリティです。なぜなら、管理アクセスをどのように構築したいかによって、管理アクションはより多くのことができる可能性が高く、承認の量を削除または制限するなどの特定のセキュリティ制限を回避できるからです。
リソースの入れ子については、意味がある場合は使用してください。親リソースのコンテキスト外でネストされたリソースのいずれかにアクセスしたくない場合は、ネストされたリソースを使用することをお勧めします。
例として、管理インターフェースがサプライヤーによってアクセスされ、各管理者がサプライヤーのリソースのみにスコープされる場合、そのネストされたリソースを単純にクエリでき、承認がアカウントがそのサプライヤーに関連付けられていることを確認するだけです。
class Admin::ProductsController < AdminController
before_filter :load_supplier
# your actions
def load_supplier
# Will trigger a 404 if the supplier does not belong to the admin
@supplier = current_admin.suppliers.find(params[:supplier_id])
end
end
もちろん、それはあなたが達成しようとしていること、管理領域の予想される聴衆が何であるか、彼らがすべてに完全にアクセスできるかどうかに大きく依存します. その場合、関係のコンテキスト外のリソースにアクセスする必要があります。たとえば、私が管理者で、サプライヤーに関係なくすべての製品に対して検索/並べ替え/フィルター処理を実行し (または 1 つ以上のサプライヤーでフィルター処理)、それらの制約から CSV/Excel を生成する必要があるとします。 . この場合、ネストされたリソースを使用すると、これが困難または不可能になる可能性があります。
個人的には、ネストされたリソースは、ユーザー/パブリックに面したコントローラーではより理にかなっており、管理領域ではより面倒であることがわかりましたが、それから私は常に少数の人に限定された管理インターフェースを構築してきました. その場合、私は通常、多くのカスタマイズオプションを備えた各モデルで基本的に完全な CRUD を提供する ActiveAdmin のような宝石に目を向けます。