コントローラー階層

私が見たほとんどのRailsプロジェクトでは、コントローラー構造に組織がなく、プロジェクトは必要に応じて成長しています。 大規模なプロジェクトでは、これによりコントローラーが巨大になり(数十のアクションがある)、条件フィルターがフルスクリーンに拡大されるという事実につながります。 このコードを理解することは非常に困難です。



多数のRailsプロジェクトで作業した後、コントローラーの階層を整理するアプローチを開発しました。これにより、コントローラーの構造を統一し、コードを簡素化することができました。







トップレベル





まず、Web、モバイル、API、フィードなどの主要プロジェクト名を上位レベルに配置すると便利です。 この場合、管理モジュールはWeb上に配置されます。







API内では、バージョンごとに分割されたサブモジュール(v1、v2など)も選択できます。 または、最上位のapi1、api2などにフォルダーを作成します。

リンク: freelancing-gods.com/posts/versioning_your_ap_is



最も単純な場合でも、このような構造を使用します。 実践では、これらのコンポーネントは誰も計画していなくても簡単に追加できることが示されています。



モジュールごとに、特定の名前空間に適したロジックを混在させないために、Namespace :: ApplicationControllerが作成されます。







ただし、ルーティングでは、モジュールごとにわずかな違いがあります。 Webはスコープとして設定されます。 その結果、不必要なプレフィックスなしでヘルパーを取得しますが、残りにはネームスペースが使用されます。







入れ子になったリソース





例からすぐに始めます。サイトのユーザープロフィールです。 url / users /:idおよびそのUsersControllerコントローラーからアクセスできます。 ユーザー投稿のリストは/ users /:id / postsにあります。 したがって、ユーザーが投稿を取得するインデックスを持つPostsControllerがあります。 次に、すべての投稿を1つのリストに表示するタスクがあります。 同じ投稿コントローラーを使用し、そこにindex_allメソッドを追加します。 同時に、ここではユーザーは不要になりました。 最後に、多くのビューを追加して、これらの投稿をユーザーに表示(および処理)するメソッドと、表示しないメソッドがあります。 次に、例えばbefore_filter:load_user ,: only => [:index ...]などのフィルターがあり、ここで何が起こっているかを理解できる人が残るまで続きます。



同じことを繰り返して、コメント、いいねなどを表示します。 同時に、投稿の出力はユーザーごとだけでなく、カテゴリごと、投稿にリソースが投資される他の多くのリンクごとにも出力できます。



この場合、対応するリソースのモジュールを作成することも賢明です。







また、各名前空間には、共通のモジュールメソッドを含む独自のApplicationControllerがあります。







このモジュールにあるすべてのコントローラーについて、フィルターなしのcurrent_sectionが使用可能になります。



利益:



コントローラーはより小さくシンプルになっています。

コントローラーの構造を見ると、プロジェクトがどのように構成されているか、特定のコントローラーで何が期待できるかについて多くのことが言える。

多くの条件フィルターはなくなります。

テストが簡素化されます。

統一された組織的アプローチ。



また、利便性と統一性のために、名前空間入力コントローラーは歓迎と呼ばれます。 そして、それらはルートを介してルートで接続されます:to => 'welcome#index'対応するスコープ内。

実際の例:



実際の例でコントローラーを編成する方法を考えてみましょう。 Facebookとの統合を行う必要があるとします。



額に近づくと、何らかの種類のFacebookControllerコントローラーが作成され、そこにFacebookを操作するためのすべてのメソッドが配置されます。 その結果、メソッドの一部を取得します。これはユーザーアカウントからのみ機能し、権限のないユーザーなどに対してのみ機能します。



分離アプローチ:



resource :facebook, :only => [:new, :create]
      
      







この場合、ユーザーについてはまだ何もわかっていませんが、統合を変更する(たとえば、自動共有を設定する)か削除するときは、特定のユーザーと連携します。 これは、たとえば次のように実装できます。



 # app/controllers/web/account/facebook_controller.rb resource :account do scope :module => :account do resource :facebook, :only => [:edit, :update, :destroy] end end
      
      







そして、すでに許可されたユーザーを統合する機会を与える必要がある場合はどうでしょうか? 次に、最後の例でadd:new ,: createを追加します。



その結果、1つのコントローラーではなく、2つ(ただし、タスクで必要な場合はさらに多く)が得られましたが、同時に、すべてのメソッドはユースケースごとにグループ化されています。



All Articles