Rieles ¿Lógica en controladores?

Question

Siempre estoy leyendo sobre mantener los Controladores delgados y haciendo toda la lógica en los modelos. Si bien esto me da sentido para interactuar con las bases de datos, ¿qué pasa con las situaciones en las que no hay necesidad de interacciones con la base de datos?

Tengo un módulo bastante complejo en mi aplicación que interactúa con varias API de terceros diferentes. Uso las llamadas ajax a mi controlador, donde todos los datos se recopilan de las API y luego se organizan. Luego se muestra a través de los archivos .js.erb o .html.erb correspondientes.

¿Es esta la manera correcta de manejar este tipo de situación? Soy nuevo en los raíles y no quiero acostumbrarme a hacer las cosas mal.

Answer 1

Los modelos no son solo para manejar bases de datos, sino también para trabajar con datos.

Por lo que no sabemos a qué situaciones se refiere, puedo presentar algunas situaciones.

Llamada de Ajax para grandes cálculos matemáticos. No está tocando la base de datos e incluso puede calcularse en un modelo sin tablas.

# in your controller 
def calculating 
    Calculator.get_integral_log_and_furie params[:data] 
end 
# in your model 
class Calculator 
    def self.get_integral_log_and_furie(data) 
    ... # multi line code 
    end 
end 

Así se puede ver que se puede calcular la derecha en su controlador, pero se debe calcular en el modelo, por lo que es una solución reutilizable y limpio.

Otro ejemplo es el uso de algunos atributos virtuales. Nombres. Puede almacenar primero, segundo y tercer nombre en columnas separadas, por lo que debe unirse a él. Puede crear método privae en el controlador, pero por supuesto es una mala idea.

class User < AR::Base 
    def full_name 
    [first_name, second_name, third_name].compact.join(" ") 
    end 
end 

lo tanto se le puede llamar por todas partes en su proyecto:

@user.full_name 
# Peter Jhonson, or mu is too short 

Y así sucesivamente y así sucesivamente

Answer 2

Esa es una buena pregunta.

Incluso si no necesita usar una base de datos, puede seguir un enfoque OOP/MVC para organizar su código y ajustar sus datos, lógica y comportamiento en los modelos.

La organización de código y el encapsulado dentro de los objetos del modelo sigue siendo útil & ¡importante!

En Rails 3, puede hacer que los modelos no persistentes incluyan solo algunos de los módulos de ActiveModel que contiene ActiveRecord. Por ejemplo:

# This class exists as a fairly simple DTO that is not expected to be persisted, but 
# it does have validation, attributes & a hash constructor, just like ActiveRecord models 
class MyProduct 
    include ActiveModel::Conversion 
    include ActiveModel::Naming 
    include ActiveModel::Validations 

    attr_accessor :title, :quantity 

    validates :title, :quantity, :presence => true 
    validates :quantity, :numericality => {:greater_than_or_equal_to => 1} 

    def initialize(attributes = {}) 
    attributes.each do |name, value| 
     send("#{name}=", value) 
    end 
    end 

    def persisted? 
    false 
    end 
end 

Answer 3

Realice la lógica del modelo en los modelos.

• Mantener las asociaciones.
• Mantener atributos complejos.
• Mantener las validaciones.
• Representa conceptos del negocio/industria.

Do controller logic in controllers.

• Compruebe que un usuario está autorizado a modificar un recurso.
• Extraiga y agregue datos para pasar a una plantilla de vista.
• Encuentra la plantilla de vista correcta.
• Componer json para la respuesta de la API.
• Reintentar errores de guardado.

Los modelos no necesitan ser ActiveRecord s. Puede hacer mucho con los modelos, el "núcleo" de su aplicación, que no tiene nada que ver con la persistencia. Simplemente no coloque la lógica del controlador en estos modelos.