1

私はレールコードでこれをいつも見ています：

before filter :get_post, only: [:edit, :update, :destroy]

def edit
  # code .......
end

def update
  # code .......
end

def destroy
  # code .......
end

private
  def get_post
    @post = Post.find(params[:id])
  end

同じコード行を 3 回繰り返さないことは理解していますが、インスタンス変数と before フィルターを非表示にせずにコードをプライベート メソッドにリファクタリングするだけで、読みやすく、同じことを達成するためのより良い方法はありませんか? ?

private
  def get_post(post_id)
    Post.find(post_id)
  end

次に、インスタンス変数をアクションに保持できます

def edit
  @post = get_post(params[:id])
end

プライベート メソッドでインスタンス変数を非表示にすることは、概念的に意味がありません。なぜこれがレールで非常に一般的ですか?

4

5 に答える 5

3

この特定の慣行については、おそらくさまざまな意見が見られるでしょう。個人的に、私はあなたに同意します。DRY に厳密に従っていることは、ファイルの下部にあるメソッド内のインスタンス変数を隠すことによって、少し混乱を招くだけだと思います。get_postメソッドが本当にあなたを本当に買うのかどうか、私自身も確信が持てません。とは言っても、私は多くの場合、簡潔さよりも明快さ (それが言葉である場合) を好む傾向があり、すべてのコントローラーで一貫してこのトリックを使用するチームの場合、混乱は (あったとしても) それほど多くないかもしれません.

フィルターがもう少し複雑にカプセル化されている場合は、それだけの価値があるかもしれません。たとえば、Ryan Bates による人気の認証ライブラリCanCanは、RESTful リソースが自動的に読み込まれ、現在のユーザーに対するアクセスが認証されるようにload_and_authorize_resourceをインストールする、コントローラー クラス マクロを導入しています。before_filterこれは、メソッドごとに 1 行または 2 行を超える可能性があり、毎回逐語的に繰り返されるわけではありません。

一部の Rails 開発者が使用する一般的な中間点があります。これは をbefore_filterブロックとして指定するため、繰り返す必要はありませんが、インスタンス変数はファイルの先頭にあります。

before_filter(only: [:edit, :update, :destroy]) do
  @post = Post.find(params[:id])
end

コメントで述べたように、このパターンを形式化し、「隠された」または混乱を大幅に軽減するのに役立ちます (明示的に宣言され、API が既知であるため) のようなgemがいくつかあります。

于 2013-05-14T05:23:04.770 に答える
1

あなたの提案は、典型的なRailsの慣習よりも改善されていると思います. ただし、さらに一歩進んで、インスタンス変数を完全に削除します。インスタンス変数を使用するのは誤解を招く可能性があります。これは、通常、複数のコントローラー アクション間で共有されている状態を表しておらず、多くの場合、どのメソッド間でも共有されていないためです (それを割り当てる before フィルターを除く)。

ビューで使用するためにインスタンス変数を生成するという Rails の規則は、その使用をなくすべき悪い考えです。クリーンな MVC 実装では、コントローラーからの何もビューで使用できません。これは、レイヤーを適切に分離する、よりクリーンな実装だと思います。

def edit
  post = get_post(params[:post_id])
  render 'edit', locals: { post: post }
end

リーク状態がなく、ビュー内のインスタンス変数に依存せず、明示的な意図があり、より簡単に再利用でき、ハッキーなインライン インスタンス変数の割り当てを挿入することなく、他のビュー内からレンダリングできるビュー。

Rails には、迅速なブートストラップを可能にする多くの規則がありますが、それらは適切なコードにはなりません。

于 2013-05-14T06:03:17.513 に答える
0

を使用した別のアプローチもありhelper_methodます。見た目はほぼ希望通りです。

http://rails-bestpractices.com/posts/57-substituting-before_filter-load_object

于 2013-05-14T06:06:54.190 に答える
0

これは、設定よりも規則です。

どちらのアプローチも間違っていませんが、Ruby が好きな人は、最小限のコーディング パターンを好むことが多く、問題を解決するための最速のアプローチを使用して、より複雑で興味深い問題の解決に取りかかることを重視します。

このアプローチが十分に頻繁に使用されているのを見たことがあれば、コードを定義する前に、すべてのメンバー関数 (コレクション関数ではないことは明らかです) にメンバー変数を事前にロードさせることが第二の性質になります。関数でメンバー変数を指定しても、(もしあれば) 明確な利点が得られないところまで来ています。

于 2013-05-14T05:33:09.317 に答える