ruby on rails - rubyonrails - ¿Por qué Rails 5 usa ApplicationRecord en lugar de ActiveRecord:: Base?

ruby on rails tutorial

Question

Sabemos que Rails 5 agregó ApplicationRecord como una clase abstracta que heredaron nuestros modelos (ActiveRecord).

Pero, básicamente, creo que todos los requisitos técnicos que hacemos con ApplicationRecord, también podemos hacer con ActiveRecord::Base . Por ejemplo:

module MyFeatures
  def do_something
    puts "Doing something"
  end
end

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

Entonces ahora a cada modelo se le atribuirán los comportamientos de MyFeatures . Pero también podemos lograr esto en Rails 4:

ActiveRecord::Base.include(MyFeatures)

Entonces, ¿cuál es el beneficio de usar ApplicationRecord , crees que es necesario agregar ApplicationRecord ?

Answer 1

Esto es para expandir la respuesta de @ BoraMa y, con un poco de suerte, despejar la confusión sobre ActiveRecord::Base.abstract_class .

ActiveRecord::Base.abstract_class se remonta al menos a Rails 3.2.0 ( http://api.rubyonrails.org/v3.2.0/classes/ActiveRecord/Inheritance/ClassMethods.html ), que fue lanzado el 20 de enero de 2012.

Rails 4.0.0 mejoró la documentación: http://api.rubyonrails.org/v4.0.0/classes/ActiveRecord/Inheritance/ClassMethods.html

Entonces, para todos los que piensan que ApplicationRecord es radicalmente nuevo, no lo es. Es una mejora, no un cambio de ruptura. No se agregó nada a ActiveRecord::Base para que esto funcione.

Hice lo mismo en un proyecto de Rails 4.2.6 porque los modelos usaban UUID para identificadores en lugar de enteros, y esto requería un cambio al ORDER BY predeterminado. Entonces, en lugar de usar copiar y pegar o una preocupación, fui con la herencia usando una clase self.abstract_class = true y self.abstract_class = true .

Answer 2

Si bien puede parecer lo mismo en las aplicaciones básicas de Rails, en realidad hay una diferencia importante una vez que comienzas a utilizar motores de rieles, complementos / gemas o métodos directos de ActiveRecord::Base .

• ActiveRecord::Base.include(MyFeatures) mezcla las características directamente en ActiveRecord::Base y está presente allí para siempre para todos los usos posteriores de ActiveRecord::Base (no puede ser "sin mezclar") y no hay forma de obtener el original ActiveRecord::Base más en cualquier código después del include. Esto puede provocar problemas fácilmente si parte de la característica mixta cambió el comportamiento predeterminado de ActiveRecord o si, por ejemplo, dos motores / gemas intentaron incluir los mismos métodos.

• Por otro lado, el enfoque ApplicationRecord hace que las funciones estén presentes solo para las clases (modelos) que heredan de él , otras clases, así como para el uso directo de ActiveRecord::Base stay pristine, sin las características del módulo.

Esto es especialmente importante cuando se utilizan complementos de motores o raíles, ya que les permite separar su propia lógica de modelo de la lógica de modelo de la aplicación principal, lo que no era posible antes de ApplicationRecord .

Todo esto también está muy bien descrito en esta publicación de blog y este comentario github .