私はいくつかの質問に対する答えを探していたので、この記事はここにあります。 私にとって、この記事を理解するのは簡単な読み物ではなく、手動で翻訳する必要がありました。 おそらく誰かがこのトピックに興味を持つでしょうが、英語は私のものよりも悪いでしょう。 あなたを助けるために転送します。



元の記事は、Jerome's Adventures in Softwareで読むことができます。

DHH（David Heinemeyer Hensson）がレールコントローラを整理する方法

Full Stack Radioとの最近のインタビューで、教祖であり救世主であるDHHは、最新バージョンのBasecampでコントローラーのレール構造をどのように整理するかについて説明しました。 ここに彼の聖なる言葉の転写があります：



コントローラーの作成におけるほぼ原理主義者として、私はRESTにコミットし続けています。



コントローラーに不満を感じるたびに、これは私がコントローラーをほとんど持っていないからです。 私はそれらを過負荷にしようとしています。



そのため、Basecamp 3では、ある種のサブリソースが存在するたびにコントローラーを超えていました。 それらはフィルターとして機能できます。



このコードがあり、次のようになっているとします：

class BananasController < ApplicationController def index render plain: '\_(:-))_/' end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

いくつかのフィルターとドロップダウンメニューを適用する場合、これは別のものになります。 時々、私たちはこれを取り、それのために完全に新しいコントローラーを実行します。



私が特に仕事に使用するヒューリスティックです：コントローラーに新しいアクションを追加したいときはいつでも、このアクションはデフォルトで5つのアクションの1つに含まれていません。つまり、この欲求を満たし、新しいコントローラーを作成するだけです。 ！ だから私はそれを呼び出します。



したがって、InboxController（メールボックスコントローラー）があり、メールボックス内のすべてを表示するインデックスアクションがあるとします。 また、「保留中の新しいアクションを追加したい場合は、保留中のメールなどのようなものになります」という別のアクションを実行できます。



そして、このアクション保留を追加します：

  class InboxesController < ApplicationController def index end def pendings end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは非常に一般的なテンプレートですよね？ そして、私が使用するサンプルでさらに説明できます。 次に、「いいえ、いいえ、いいえ」と言って、Inboxes :: PendingsControllerという新しいコントローラーを作成します。このコントローラーには、1つのインデックスアクションがあります。

  class InboxesController < ApplicationController def index end end class Inboxes::PendingsController < ApplicationController def index end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、ここで私がその自由を見つけたのは、各コントローラーに独自の適用分野があり、独自のフィルターセットが適用されているという事実です...



そのため、コントローラーの大規模な分布、特に名前空間でのコントローラーの分布があります。 MessagesControllerがあり、Messages :: DraftsControllerコントローラーとMessages :: TrashesControllerがあり、これらすべてのサブコントローラーとサブリソースが同じコントローラー内にあると仮定しましょう。 私の意見では、これはクールです。



アーメン



基本的に、彼はコントローラーが標準のCRUDアクションのインデックス、表示、新規、編集、作成、更新、破棄のみを行うべきだと言った。 その他のアクションは、CRUDアクションのみを持つコントローラーの作成につながるはずです。

私はこれについてどう思いますか

次は私自身の信念です。 確かに、意見の違いがいくつかあります。 私はただ、狂信者とは呼ばないでください。 落ち着いて



いずれにせよ、私はこれを知ってうれしく、「DHHの方法」（David Heinmeier Henssonの方法）を使用してコントローラーを1年以上、今日まで#DHHFanboyで編成してきました。 単純なコントローラーロジックの例が冗長であることは明らかですが、フィルタリングの例のみに言及しています。 RESTでフィルターを使用する一般的な方法は、たとえばリクエストパラメーターを使用することです（例：GET / inboxes？State = pending）。



一般に、コードは短くてシンプルでなければならないという事実に固執します（長く複雑で、アクションと関係が非常に複雑になるとすぐに-Davidと同じことをします）。 しかし、コントローラーを分離するという主な考えには同意します。これにはいくつかの理由があります。

これにより、簡単なコードを作成できます。

この手法を使用すると、必要な数のコントローラーを作成できます。 ただし、個人的な信念を使用してください：簡潔さとシンプルさに関するデフォルトのコントローラー（CRUDアクション付き）がある場合（レールに足場を置くなど）、おそらく各インデックス/ショー/などを独自のコントローラーに抽出する必要はありません。



コントローラーの分離技術は、CRUDアクションという唯一の欠点にもかかわらず、コントローラー自体がより強力になると改善されます。 この場合の対処方法 このコードは、そのためのコントローラーで作成するだけです。



たとえば、ここで最も洗練されたコントローラーは現在の会社のように見えます（小さなモデルとかなり大きなコントローラー、YMMVを使用します）YMMV-走行距離は異なる場合があります（同じものを異なる方法で使用できます） 。 これにより、APIアプリケーションで製品を購入できるようになります。

  class Api::V1::PurchasesController < Api::V1::ApplicationController rescue_from Stripe::StripeError, with: :log_payment_error def create load_product load_device load_or_create_user create_order create_payment authorize_payment confirm_address render json: @order, status: :created end private def load_product @product = Product.find_by!(uuid: params[:product_id]) end # … end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パブリックCRUDメソッドは1つだけです（デフォルトではアクションを作成します）「シック」モデルには時期尚早な抽象化はありません。サービスクラスもオブザーバーもありません。ゴミもありません。 すべてがここにあります。 コントローラーに便利に配置。 何が起こっているのかを理解するためにたくさんのファイルにジャンプする必要はありません。 エディタでこの単一のファイルを開くだけです。 また、コントローラーはWebアプリケーションコードのエントリポイントであるため、コーディング中にこのファイルを開く必要があります。 #ObviousCode



しかし、おそらくあなたは「ホスパディ、このクラスはどれくらい大きいか、何を詰め込んでいますか？」と尋ねるでしょう。もちろん、それは非常に大きく、まるで...要するに大きいですか？ いいえ、わずか144行で、これが最も複雑なコントローラーです。 最悪の最悪をまっすぐに。 もちろん、コードを小さな断片に分割することもできますが、私たちにとってこれは非常に正常です（YMMV）。 残りのコントローラーは、6〜103行で、平均で1つのコントローラーである15行で、はるかに単純です。 （現時点では150個のコントローラーがあります）。



コントローラーに200行以上のコードがあり、これはリクエストのごく一部であり、残りは無限のサービスオブジェクト、モデル、オブザーバー（サービスオブジェクト、オブザーバー、モデル）に散在しているプロジェクトを覚えていますか？ この種のことは、コントローラーを単純なもの（ 通常は3つ）に分割するこの手法のおかげで、ここでは発生しません。



実際、複製は誤った抽象化よりも害が少ないため、DRYとSRC（DHHの方法を含む）が非常に過大評価され、卑劣なでたらめに満ちていて、 ボールを吸ったり、...と思う理由の1つです。 トピックに戻りましょう！

コードをより均一にします

コントローラーにCRUDアクションの束しか存在しないことを知っても、実際には役に立ちません。 理解できないアクションを見つけるために、大きなコントローラーで推測やスクロールをする必要はもうありません。 通常のアクションがルート（ルート）に表示される場合、どのように/興味深いものではありません。



単純な組織を作るとき、私は驚かないのが好きです。 私は、コードの統一性、統一されたコード、および強力な「構成より規約」が好きです。これが、他のRubyフレームワークよりもRailsを好む理由の1つです。 すべてが同じように編成されているため、日常的な意思決定に費やす時間を短縮し、ビジネスにとって本当に重要な分野で成功することができます。



理論的には、これは、あるコードから別のコードに移動し、非常に短い時間で100％の生産性を実現できることも意味します。 荒野では、人々は「ひどいRailsアプリケーション」を理解するようになります。 ある会社はオブザーバー（私のお茶ではありません）などの建築パターンを使用でき、別の会社はTrailblazer（私のお茶ではありませんが、これについて興味深いアイデアがあります）などの追加のアーキテクチャを使用できます。 4番目は一般的に独自のものなどです。



これはすべて、人々がバニラRailsアプリケーションのいわゆる「構造の欠如」に不満と不満を抱いているという事実によるものです。 そこで彼らは他の場所で追加の構造を探しています。 ゲイズ！ 解決策はあなたの鼻の下にあります。 コントローラーを分離し、CRUDアクションのみを使用します。 2倍簡単でジュニアフレンドリー。



Railsは、コントローラーのヒューリスティックな分離を促進するより良い仕事をすることができます。 彼らのドキュメントには、「...通常はINVENTIVEルーティングを使用する必要があります...」と簡単に書かれていますが、CRUDアクションとRESTfulの概念は、ドキュメント内で長い間はっきりとわかります。



RTFMを使用している場合（RTFM-クソマニュアルをお読みください）、カスタムアクション（CRUDを除く）を追加することは「レールの方法」ではないことを少なくとも一度は考えたことがあると思います。

RESTについて考えるようになります。

RESTは、このアーキテクチャスタイルが統一されておりシンプルであるため、多くの人々に愛されています。 RESTfulを理解する（実際に理解する）と、もう一方を理解しやすくなります。



理論的には、少なくとも：全員の認証？ ;-)ビジネスロジックはアプリケーション間で明らかに異なるため、これを理解する必要がありますが、ロジックはどこでも似ていることをどのように理解しますか。 つまり、Stripeで費用を作成し（誰かのお金を取る）、TwilioでSMSを作成し（つまり送信）、Githubでストレージを取得します。



アクションの代わりに名詞を使用して、RESTを使用するために最初に頭を少し緊張させる必要があります。「支払う」ではなく、「支払いを作成する」ではなく「残高に資金を追加する」ではなく、バランスシートの資本（「バランスで資金を作成する」）など。 少し奇妙かもしれませんが、SOAP、WSDL、その他のものに戻るよりも毎週この価格を支払うことになります（元Java / JEE開発者は私が話していることを知っています）。



さらに、インターフェイスのすべてのビジネスロジック（必ずしも実装である必要はありません）がRESTによって決定されます。RESTは、より簡潔でシンプルなビジネスロジック用に作成されたものであり、 。 それまでは、RESTで何でも表現できることを知っています。それは明らかです。 これにより、制限がなくなります。



CRUDアクションのみを使用して共有コントローラーを表すRESTful Railsルートの例を次に示します。

  resources :purchases, only: :create resources :costs_calculations, only: :create namespace :company do resource :account_details, only: :update resource :website_details, only: :update resource :contact_details, only: :update end namespace :balance do resources :funds, only: :create end resource :bank_account, only: :update
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

REST設計を改善するために（特に子リソースが接続されている場合）、実装を気にせずに、タイムスタンプ（POST /残高/資金）の先頭にアクション+リソースを記述するときに、通常RESTを省略します。 それから、名前が割り当てられたとき、私は落ち着いています。 RailsはRESTを適切にサポートしているため、すべてをRailsルートに変換します。これは非常に便利です。

おわりに

コントローラーのスケールが非常に大きく、ロジックが多すぎたり、困難が多すぎる場合にコントローラーを分離すると、コードに良い影響を与える可能性があります。



これは「抽象化を忘れる」という意味ではありません。 少し低くなります。 一部のポイントとロジックには、混合コントローラーが必要です。 パブリックアクションが1つしかないコントローラを分割した場合でも大きく見える場合があります。 これはモデルのメソッドにも当てはまります。神が私を許してくれるかもしれませんが、ここでサービスオブジェクトが登場します（残念ながら、サービスオブジェクトは注意してください。



アプリケーションが大きくなればなるほど、コードがどれだけクリーンであっても、これを理解するために費やす時間が長くなります。 しかし、分離コントローラーは物事を簡単にします。