2015-12-07 1 views
1

Рассмотрим следующийЯвляется ли before_action/filter в application_controller.rb плохой практикой?

class ApplicationController < ActionController::Base 
    # Prevent CSRF attacks by raising an exception. 
    # For APIs, you may want to use :null_session instead. 
    protect_from_forgery with: :exception 

    before_filter :maintenance_mode 

private 

def maintenance_mode 
     @settings = Setting.first 
     if @settings.maintenance 
     if logged_in? 
      if !current_user.admin? 
      redirect_to maintenance_url 
      end 
     else 
      redirect_to maintenance_url 
     end 
     end 

end 

есть ли проблема с производительностью или плохой практикой в ​​целом использовать before_actions во всем мире? Поэтому я создал режим обслуживания, где, если в базе данных есть истинное значение для атрибута обслуживания (который будет проверяться при каждом запросе, который я предполагаю), и, скорее всего, это не самый лучший способ, так есть ли в этом обход?

Я могу представить себе задачу задания/рейка cron, проверяющую каждую минуту в фоновом режиме, но то, что я действительно хочу знать, это before_action - плохая вещь вообще?

ответ

1

Вы можете пропустить ненужные логику и запросы с помощью сеанса и кэш

class ApplicationController < ActionController::Base 
    # Prevent CSRF attacks by raising an exception. 
    # For APIs, you may want to use :null_session instead. 
    protect_from_forgery with: :exception 

    before_filter :maintenance_mode 

    private 
    def maintenance_mode 
    unless session[:maintainence_mode].present? 
     @settings = Rails.cache.fetch { Setting.first } 
     session[:maintainence_mode] = @settings.maintenance 
    end 

    if session[:maintainence_mode] 
     if logged_in? 
     if !current_user.admin? 
      redirect_to maintenance_url 
     end 
     else 
     redirect_to maintenance_url 
     end 
    end 
    end 
end 

Таким образом, вы можете позвонить before_filter чем будет большую часть времени проверить, если значение в session[:maintanence_mode] устанавливается или не вместо выполнения запрос каждый раз.

Вы должны также использовать Rails.cache или cookies

Использование рельсов кэш для извлечения или получить Setting моделируют

@settings = Rails.cache.fetch { Setting.first } 

или

с использованием cookies для хранения значения вместо session, который дает вам поддержку для истечение срока действия

cookies[:_mmode] = { :value => @settings.maintanence,\ 
    :expires => 1.hour.from_now } 
+0

Возможно, мне что-то не хватает, но если я нахожусь на вашем сайте, пока он находится в режиме обслуживания, моя сессия всегда думает, что сайт находится в режиме обслуживания, который не кажется правильным; Мне нужно будет дождаться окончания сеанса до повторного использования сайта. Ужасный пользовательский интерфейс объединяется для лучшей производительности (что может и не понадобиться). – house9

+0

Я согласен с вами в том, что хранение его в сеансе является ошибкой, если это так, как вы говорите. Но есть альтернативы, такие как файлы cookie и кеш, которые могут истечь. Я предпочитаю кеш, если он предназначен для всех пользователей. –

+0

@MohamedOsama, как вы работаете с этой строкой '@settings = Rails.cache.fetch {Setting.first}', поскольку он говорит 'неправильное количество аргументов (0 для 1..2)' –

2

Я не считаю, что before_action не хуже, чем что-либо еще. Вероятно, вам нужно будет реализовать skip_before_action в ваших других контроллерах на определенных маршрутах, а некоторые рефакторинг с помощниками контроллера могут позволить избежать дополнительных запросов к базам данных. В целом, прежде чем действия станут основной полезностью рельсов, а не то, что стоит избегать по соображениям производительности.

 Смежные вопросы

  • Нет связанных вопросов^_^