デフォルトの Rails 4 プロジェクト ジェネレーターは、コントローラーとモデルの下に「concerns」ディレクトリを作成します。ルーティングのconcerns の使用方法についての説明はいくつか見つかりましたが、コントローラーやモデルについては何も見つかりませんでした。
これはコミュニティの現在の「DCI トレンド」に関係していると確信しており、試してみたいと思います。
問題は、この機能をどのように使用すればよいか、これを機能させるために命名/クラス階層を定義する方法に関する規則があるかどうかです。モデルまたはコントローラーに懸念事項を含めるにはどうすればよいですか。
ベストアンサー1
それで、私は自分でそれを見つけました。それは実際にはかなりシンプルですが強力な概念です。以下の例のように、コードの再利用に関係しています。基本的に、モデルをクリーンアップして、モデルが肥大化したり乱雑になったりしないようにするために、共通またはコンテキスト固有のコード チャンクを抽出するという考え方です。
例として、よく知られているタグ付け可能なパターンを 1 つ挙げます。
# app/models/product.rb
class Product
include Taggable
...
end
# app/models/concerns/taggable.rb
# notice that the file name has to match the module name
# (applying Rails conventions for autoloading)
module Taggable
extend ActiveSupport::Concern
included do
has_many :taggings, as: :taggable
has_many :tags, through: :taggings
class_attribute :tag_limit
end
def tags_string
tags.map(&:name).join(', ')
end
def tags_string=(tag_string)
tag_names = tag_string.to_s.split(', ')
tag_names.each do |tag_name|
tags.build(name: tag_name)
end
end
# methods defined here are going to extend the class, not the instance of it
module ClassMethods
def tag_limit(value)
self.tag_limit_value = value
end
end
end
したがって、Product サンプルに従って、任意のクラスに Taggable を追加し、その機能を共有できます。
これは次のように説明できる。DHH:
Rails 4 では、自動的にロード パスの一部となるデフォルトの app/models/concerns および app/controllers/concerns ディレクトリで、プログラマーが concern を使用するように促します。ActiveSupport::Concern ラッパーと組み合わせると、この軽量なファクタリング メカニズムを輝かせるのに十分なサポートになります。