Pourquoi Rails 5 utilise ApplicationRecord au lieu de ActiveRecord :: Base?

Question

Nous savons que les Rails ajouté 5 ApplicationRecord comme une classe abstraite qui a été transmise par l'un de nos modèles (ActiveRecord).

Mais fondamentalement, je pense que chaque exigence technique que nous faisons avec ApplicationRecord, nous pouvons aussi le faire avec ActiveRecord::Base. Par exemple:

module MyFeatures
  def do_something
    puts "Doing something"
  end
end

class ApplicationRecord < ActiveRecord::Base
  include MyFeatures
  self.abstract_class = true
end

Alors maintenant, tous les modèles sont joints les comportements d' MyFeatures. Mais nous pouvons aussi réaliser des ce dans les Rails 4:

ActiveRecord::Base.include(MyFeatures)

Alors, quel est l'avantage de l'utilisation de ApplicationRecord, pensez-vous qu'il est nécessaire d'ajouter de l' ApplicationRecord?

Answer 1

Bien que cela semble être la même de base, les applications Rails, il y a réellement une différence importante une fois que vous commencez à utiliser des rails de moteurs plugins / gemmes ou des méthodes directes d' ActiveRecord::Base.

• ActiveRecord::Base.include(MyFeatures) de mélange dans les fonctionnalités directement dans ActiveRecord::Base et il est présent, toujours là pour toutes les utilisations ultérieures de l' ActiveRecord::Base (il ne peut pas être "mélangés") et il n'y a aucun moyen d'obtenir l'original ActiveRecord::Base plus dans le code après le comprennent. Cela peut facilement conduire à des problèmes si certains mixte de la fonction changé la valeur par défaut ActiveRecord comportement ou si par exemple deux moteurs / gemmes essayé d'inclure même nom des méthodes.

• D'autre part, l' ApplicationRecord approche rend les fonctionnalités disponibles uniquement pour les classes (modèles) qui héritent de lui, d'autres classes, ainsi que l'utilisation directe d' ActiveRecord::Base rester vierge, épurée par les caractéristiques du module.

Ceci est particulièrement important lorsque les moteurs ou les rails, les plugins sont utilisés, car il permet de séparer leur propre modèle logique de l'application principale du modèle logique qui n'était pas possible avant d' ApplicationRecord.

Tout cela est également bien décrite dans ce blog et cette github commentaire.

Answer 2

C'est à développer sur @BoraMa réponse, et pour, espérons-le, dissiper une certaine confusion autour de ActiveRecord::Base.abstract_class.

ActiveRecord::Base.abstract_class remonte à au moins Rails 3.2.0 (http://api.rubyonrails.org/v3.2.0/classes/ActiveRecord/Inheritance/ClassMethods.html), qui a été publié le 20 janvier 2012.

Rails 4.0.0 l'amélioration de la documentation: http://api.rubyonrails.org/v4.0.0/classes/ActiveRecord/Inheritance/ClassMethods.html

Donc, pour tous ceux qui pensent ApplicationRecord est radicalement nouveau, il ne l'est pas. C'est une amélioration, et non d'une modification de rupture. Rien n'a été ajouté à l' ActiveRecord::Base pour faire ce travail.

J'ai fait la même chose sur les Rails 4.2.6 projet parce que les modèles utilisés Uuid pour id au lieu de nombres entiers, ce qui exige une modification de la valeur par défaut ORDER BY. Donc, au lieu d'utiliser le copier-coller ou un souci, je suis allé avec l'héritage à l'aide d'un UuidModel de la classe et de l' self.abstract_class = true.