Verwendung von Bedenken in Rails 4

Der Standard-Rails 4-Projektgenerator erstellt jetzt das Verzeichnis "Anliegen" unter Controllern und Modellen. Ich habe einige Erklärungen zur Verwendung von Routing-Bedenken gefunden, aber nichts zu Controllern oder Modellen.

Ich bin mir ziemlich sicher, dass es mit dem aktuellen "DCI-Trend" in der Community zu tun hat und würde es gerne ausprobieren.

Die Frage ist, wie soll ich diese Funktion verwenden? Gibt es eine Konvention zum Definieren der Namens- / Klassenhierarchie, damit sie funktioniert? Wie kann ich ein Problem in ein Modell oder einen Controller aufnehmen?

Also habe ich es selbst herausgefunden. Es ist eigentlich ein ziemlich einfaches, aber leistungsstarkes Konzept. Dies hat mit der Wiederverwendung von Code wie im folgenden Beispiel zu tun. Grundsätzlich besteht die Idee darin, allgemeine und / oder kontextspezifische Codestücke zu extrahieren, um die Modelle zu bereinigen und zu vermeiden, dass sie zu fett und unordentlich werden.

Als Beispiel werde ich ein bekanntes Muster einfügen, das taggable Muster:

# 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

Wenn Sie dem Produktbeispiel folgen, können Sie Taggable zu jeder gewünschten Klasse hinzufügen und deren Funktionalität freigeben.

Dies wird von DHH ziemlich gut erklärt :

In Rails 4 werden wir Programmierer einladen, Bedenken mit den Standardverzeichnissen app / models / Concern und app / controller / Concern zu verwenden, die automatisch Teil des Ladepfads sind. Zusammen mit dem ActiveSupport :: Concern-Wrapper reicht diese Unterstützung gerade aus, um diesen leichten Factoring-Mechanismus zum Leuchten zu bringen.

Ich habe über die Verwendung von Modellproblemen gelesen, um Fettmodelle zu häuten und Ihre Modellcodes auszutrocknen. Hier ist eine Erklärung mit Beispielen:

1) Trocknen von Modellcodes

Betrachten Sie ein Artikelmodell, ein Ereignismodell und ein Kommentarmodell. Ein Artikel oder eine Veranstaltung hat viele Kommentare. Ein Kommentar gehört entweder zum Artikel oder zum Ereignis.

Traditionell sehen die Modelle folgendermaßen aus:

Kommentar Modell:

class Comment < ActiveRecord::Base
  belongs_to :commentable, polymorphic: true
end

Artikelmodell:

class Article < ActiveRecord::Base
  has_many :comments, as: :commentable 

  def find_first_comment
    comments.first(created_at DESC)
  end

  def self.least_commented
   #return the article with least number of comments
  end
end

Ereignismodell

class Event < ActiveRecord::Base
  has_many :comments, as: :commentable 

  def find_first_comment
    comments.first(created_at DESC)
  end

  def self.least_commented
   #returns the event with least number of comments
  end
end

Wie wir feststellen können, gibt es sowohl für Event als auch für Article einen wichtigen Code. Mit Bedenken können wir diesen gemeinsamen Code in einem separaten Modul Commentable extrahieren.

Erstellen Sie dazu eine commentable.rb-Datei in App / Models / Concerns.

module Commentable
  extend ActiveSupport::Concern

  included do
    has_many :comments, as: :commentable
  end

  # for the given article/event returns the first comment
  def find_first_comment
    comments.first(created_at DESC)
  end

  module ClassMethods
    def least_commented
      #returns the article/event which has the least number of comments
    end
  end
end

Und jetzt sehen Ihre Modelle so aus:

Kommentar Modell:

class Comment < ActiveRecord::Base
  belongs_to :commentable, polymorphic: true
end

Artikelmodell:

class Article < ActiveRecord::Base
  include Commentable
end

Ereignismodell:

class Event < ActiveRecord::Base
  include Commentable
end

2) Hautfettende Fettmodelle.

Betrachten Sie ein Ereignismodell. Eine Veranstaltung hat viele Teilnehmer und Kommentare.

In der Regel sieht das Ereignismodell folgendermaßen aus

class Event < ActiveRecord::Base   
  has_many :comments
  has_many :attenders


  def find_first_comment
    # for the given article/event returns the first comment
  end

  def find_comments_with_word(word)
    # for the given event returns an array of comments which contain the given word
  end 

  def self.least_commented
    # finds the event which has the least number of comments
  end

  def self.most_attended
    # returns the event with most number of attendes
  end

  def has_attendee(attendee_id)
    # returns true if the event has the mentioned attendee
  end
end

Modelle mit vielen Assoziationen und anderen Tendenzen neigen dazu, immer mehr Code anzusammeln und nicht mehr zu verwalten. Bedenken bieten eine Möglichkeit, Fettmodule zu häuten, wodurch sie modularer und verständlicher werden.

Das obige Modell kann mithilfe der folgenden Bedenken überarbeitet werden: Erstellen Sie eine attendable.rbund commentable.rb-Datei im Ordner app / models / ca. / event

attendable.rb

module Attendable
  extend ActiveSupport::Concern

  included do 
    has_many :attenders
  end

  def has_attender(attender_id)
    # returns true if the event has the mentioned attendee
  end

  module ClassMethods
    def most_attended
      # returns the event with most number of attendes
    end
  end
end

commentable.rb

module Commentable
  extend ActiveSupport::Concern

  included do 
    has_many :comments
  end

  def find_first_comment
    # for the given article/event returns the first comment
  end

  def find_comments_with_word(word)
    # for the given event returns an array of comments which contain the given word
  end

  module ClassMethods
    def least_commented
      # finds the event which has the least number of comments
    end
  end
end

Und jetzt, wo Sie Bedenken verwenden, reduziert sich Ihr Ereignismodell auf

class Event < ActiveRecord::Base
  include Commentable
  include Attendable
end

* Bei der Verwendung von Bedenken ist es ratsam, sich für eine domänenbasierte Gruppierung anstatt für eine technische Gruppierung zu entscheiden. Domainbasierte Gruppierung ist wie "Kommentierbar", "Fotofähig", "Teilnahmefähig". Technische Gruppierung bedeutet "ValidationMethods", "FinderMethods" usw.

Es ist erwähnenswert, dass die Verwendung von Bedenken von vielen als schlechte Idee angesehen wird.

1. wie dieser Typ
2. und das hier

Einige Gründe:

1. Hinter den Kulissen passiert etwas Dunkle Magie - Bedenken sind Patching- includeMethoden, es gibt ein ganzes Abhängigkeitsbehandlungssystem - viel zu viel Komplexität für etwas, das trivial gut ist, altes Ruby-Mixin-Muster.
2. Ihr Unterricht ist nicht weniger trocken. Wenn Sie 50 öffentliche Methoden in verschiedene Module einfügen und diese einschließen, verfügt Ihre Klasse immer noch über 50 öffentliche Methoden. Sie verbergen lediglich diesen Code-Geruch und legen Ihren Müll in die Schubladen.
3. Codebase ist mit all diesen Bedenken tatsächlich schwieriger zu navigieren.
4. Sind Sie sicher, dass alle Mitglieder Ihres Teams das gleiche Verständnis haben, was Bedenken wirklich ersetzen sollte?

Bedenken sind eine einfache Möglichkeit, sich ins Bein zu schießen. Seien Sie vorsichtig mit ihnen.

Dieser Beitrag hat mir geholfen, Bedenken zu verstehen.

# app/models/trader.rb
class Trader
  include Shared::Schedule
end

# app/models/concerns/shared/schedule.rb
module Shared::Schedule
  extend ActiveSupport::Concern
  ...
end

Ich hatte das Gefühl, dass die meisten Beispiele hier moduleeher die Kraft als den ActiveSupport::ConcernMehrwert demonstrieren module.

Beispiel 1: Lesbarere Module.

Also ohne Bedenken, wie ein typischer sein modulewird.

module M
  def self.included(base)
    base.extend ClassMethods
    base.class_eval do
      scope :disabled, -> { where(disabled: true) }
    end
  end

  def instance_method
    ...
  end

  module ClassMethods
    ...
  end
end

Nach dem Refactoring mit ActiveSupport::Concern.

require 'active_support/concern'

module M
  extend ActiveSupport::Concern

  included do
    scope :disabled, -> { where(disabled: true) }
  end

  class_methods do
    ...
  end

  def instance_method
    ...
  end
end

Sie sehen, dass Instanzmethoden, Klassenmethoden und eingeschlossene Blöcke weniger chaotisch sind. Bedenken werden sie angemessen für Sie injizieren. Das ist ein Vorteil der Verwendung ActiveSupport::Concern.

Beispiel 2: Behandeln Sie Modulabhängigkeiten ordnungsgemäß.

module Foo
  def self.included(base)
    base.class_eval do
      def self.method_injected_by_foo_to_host_klass
        ...
      end
    end
  end
end

module Bar
  def self.included(base)
    base.method_injected_by_foo_to_host_klass
  end
end

class Host
  include Foo # We need to include this dependency for Bar
  include Bar # Bar is the module that Host really needs
end

In diesem Beispiel Barist das Modul, das Hostwirklich benötigt. Aber da Barmuss die Abhängigkeit von Fooder HostKlasse sein include Foo(aber warten, warum Hostwill man das wissen Foo? Kann man das vermeiden?).

So Barfügt Abhängigkeit überall geht es. Und die Reihenfolge der Aufnahme zählt auch hier. Dies erhöht die Komplexität / Abhängigkeit der riesigen Codebasis erheblich.

Nach dem Refactoring mit ActiveSupport::Concern

require 'active_support/concern'

module Foo
  extend ActiveSupport::Concern
  included do
    def self.method_injected_by_foo_to_host_klass
      ...
    end
  end
end

module Bar
  extend ActiveSupport::Concern
  include Foo

  included do
    self.method_injected_by_foo_to_host_klass
  end
end

class Host
  include Bar # It works, now Bar takes care of its dependencies
end

Jetzt sieht es einfach aus.

Wenn Sie überlegen, warum können wir keine FooAbhängigkeit im BarModul selbst hinzufügen ? Das wird nicht funktionieren, da method_injected_by_foo_to_host_klasses in eine Klasse eingefügt werden muss, die Barnicht auf dem BarModul selbst enthalten ist.

Quelle: Rails ActiveSupport :: Concern

In Bedenken machen Sie die Datei filename.rb

Zum Beispiel möchte ich in meiner Anwendung, in der das Attribut create_by existiert, den Wert um 1 und 0 für update_by aktualisieren

module TestConcern 
  extend ActiveSupport::Concern

  def checkattributes   
    if self.has_attribute?(:created_by)
      self.update_attributes(created_by: 1)
    end
    if self.has_attribute?(:updated_by)
      self.update_attributes(updated_by: 0)
    end
  end

end

Wenn Sie Argumente in Aktion übergeben möchten

included do
   before_action only: [:create] do
     blaablaa(options)
   end
end

Danach nehmen Sie Folgendes in Ihr Modell auf:

class Role < ActiveRecord::Base
  include TestConcern
end