4

私はかなりの数の関連モデルを使用してアプリケーションに取り組んでおり、コントローラーを最適に編成する方法について意見を聞きたいと思っています。

ここに私が検討しているいくつかのオプションがあります:

1) コントローラーの名前空間。たとえば、controllers/admin ディレクトリと controllers/public ディレクトリを作成します。これは組織にとって魅力的に見えますが、1 つのリソースがさまざまなディレクトリに適切に属している可能性のあるアクションを持つことがよくあるため、ちょっと不自然でもあります (たとえば、show アクションは public であり、create アクションは admin です)。したがって、これは私のリソースの一部を 2 つの別個のコントローラー (1 つはパブリック、もう 1 つは管理者) に分割することを意味します。悪いようです。

2) ネストされたリソースを作成します。私はネストされたリソースをたまにしか使用していないので、リソースをネストするのが最適な場合と、必要なデータをパラメーターを介して明示的に渡すのが最適な場合が常に明確であるとは限りません。ネストされたリソースを使用する最善の方法について、提案/例を誰かが持っていますか? 良いアイデアはいつですか？オーバーキルはいつですか？

3) デフォルトの scaffolded コントローラーをそのままにしておきます。必要に応じて新しいコレクション/メンバー アクションを作成し、フィルターの前に使用して、各コントローラー内でアクセス許可を設定します。これは、前もって物事をシンプルに保つため、最も魅力的です。しかし、一部のコントローラーがいくつかの新しいアクションで膨張し始める可能性があるため、物事が混乱することに少し神経質になっています.

大規模なアプリケーションを設計した経験のある人なら、ここで何らかのガイダンスを提供できれば幸いです。

4

2 に答える 2

5

アプリケーション内で整理するために、状況に応じてすべてのことを少しだけ行いました。

まず、管理者機能とユーザー機能の別々のコントローラーに関しては、おそらくそのルートには行きたくないでしょう。承認を使用before_filterして、アプリケーション内の権利を管理しました。私たちは自分でロールバックしましたが、20/20 後知恵で、 CanCanを使用する必要がありました。そこから、次のようにセットアップできます (これは疑似コードです。実際の言語は、承認の実装方法によって異なります)。

before_filter :can_edit_user, :only => [:new, :create, :edit, :update] #or :except => [:index, :show]

protected

def can_edit_user
  redirect_to never_never_land_path unless current_user.has_rights?('edit_user')
end

またはより高いレベルで

before_filter :require_admin, :only [:new, :create]

そしてあなたのアプリケーションコントローラーで

def require_admin
  redirect_to never_never_land_path unless current_user.administrator?
end

ルートによって異なりますが、コントローラーを分割する代わりに、それを承認に使用します。

名前空間とネストされたリソースに関しては、状況によって異なります。私たちのいくつかのアプリでは、両方を備えています。論理的な分離の原因がある場合、またはコントローラーのグループ間で共有機能がある場合は、名前空間を使用します。ケースとポイントは、名前空間内に管理機能を配置し、その中にユーザー、ロール、およびその他の独自の管理機能を配置することです。

map.namespace :admin do |admin|
  admin.resources :users
  admin.resources :roles
end

そして、これらのコントローラー内に、共有関数を格納するベース コントローラーがあります。

class Admin::Base < ApplicationController
  before_filter :require_admin
end

class Admin::UsersController < Admin::Base
  def new
   ....
end

これにより、データを論理的に分離し、before_filter.

コントローラー間で何かを保持したいコードのセクションがある場合は、ネストされたコントローラーを使用します。私たちのアプリケーションのケースはお客様です。顧客を検索してロードすると、その顧客内に注文、チケット、場所があります。その領域内で、さまざまなタブを見ながら顧客をロードします。

map.resources :customers do |customer|
  customer.resources :tickets
  customer.resources :orders
  customer.resources :locations
end

これにより、次の URL が得られます。

customers/:id
customers/:customer_id/orders/:id
customers/:customer_id/tickets/:id

このことから得たその他の利点は、メニュー システムとタブの設定が簡単なことです。これらの構造は、整理されたサイトに適しています。

これが役立つことを願っています！

于 2010-07-12T02:17:43.937 に答える
0

また、1 レベル以上の深さでリソースをネストすることは、ほぼ確実に悪い考えのようです。

http://weblog.jamisbuck.org/2007/2/5/nesting-resources

ええ、それは古い記事ですが、私には非常に理にかなっています。

反対する人がいたら、その理由を聞きたいです。

于 2010-07-12T03:03:08.527 に答える