Відповіді:
Відповідно до документів , #Rails.env
обгортання RAILS_ENV
:
# File vendor/rails/railties/lib/initializer.rb, line 55
def env
@_env ||= ActiveSupport::StringInquirer.new(RAILS_ENV)
end
Але подивіться конкретно, як це загорнуто, використовуючи ActiveSupport::StringInquirer
:
Загортання рядка в цьому класі дає гарніший спосіб перевірити рівність. Значення, повернене Rails.env, загортається в об'єкт StringInquirer, тому замість виклику цього:
Rails.env == "production"
Ви можете назвати це:
Rails.env.production?
Отже, вони не зовсім рівноцінні, але вони досить близькі. Я ще не дуже використовував Rails, але, скажу, #Rails.env
це, безумовно, більш візуально привабливий варіант завдяки використанню StringInquirer
.
Rails.env
це новий стандарт, RAILS_ENV
який застарілий.
Перед Rails 2.x кращим способом отримання поточного середовища було використання RAILS_ENV
константи. Аналогічно, ви можете використовувати RAILS_DEFAULT_LOGGER
для отримання поточного реєстратора або RAILS_ROOT
отримання шляху до кореневої папки.
Починаючи з Rails 2.x, Rails представив Rails
модуль деякими спеціальними методами:
Це не просто косметична зміна. Модуль Rails пропонує можливості, недоступні за допомогою стандартних констант, таких як StringInquirer
підтримка. Також є деякі незначні відмінності. Rails.root
не повертає простий String
бут Path
екземпляр.
У будь-якому випадку кращим способом є використання Rails
модуля. Константи застаріли в Rails 3 і будуть видалені в майбутньому випуску, можливо, Rails 3.1.
Rails.env
працює без проблем.
Оновлення: в Rails 3.0.9: метод env, визначений у railties / lib / rails.rb