Поскольку веб-запросы по сути своей не имеют состояния, для каждой новой визуализации страницы потребуется откуда-то повторно извлекать данные. Ваш метод current_user
сам делает вызов базы данных за кулисами (при условии стандартной установки Devise) для загрузки пользователя при каждой загрузке страницы. Точно так же, хотя вы можете определить помощник или модуль для обмена значениями current_org
и current_project
, как указал Ритафул, им нужно будет делать вызовы базы данных для получения своих значений.
Или, по крайней мере, это типичный ответ Rails. У вас есть и другие варианты. Первый - использовать хранилище сеанса для хранения объектов либо через собственный маршалинг Ruby (опасный путь, как показали устаревшие системы, с которыми я работаю), либо через, возможно, JSON сериализацию:
# marshalling
def current_org
# this will break if your organization object contains a proc, and
# can risk exploding your session storage if your object gets large
session[:current_org] ||= current_user.organization
end
# serialization
def current_org
session[:current_org] ||= current_user.organization.to_json
end
Однако объект JSON не будет моделью ActiveRecord, поэтому ваш код придется адаптировать. Вы можете технически сделать это записью через #from_json
, но ваши отношения будут работать не так, как вы ожидаете, и в целом вы бы слишком далеко заблудились в этот момент.
В целом, я бы избегал пытается преждевременно оптимизировать ваши обращения к базе данных. Схема с правильными индексами может выполнять поиск по индексу очень быстро, поэтому такой поиск вряд ли вызовет проблему. Если вы все же начнете замечать проблемы, я бы начал с изучения нетерпеливой загрузки, чтобы уменьшить количество запросов, выполняемых при загрузке страницы, но не слишком стараться их устранить. По мере масштабирования вы можете добавлять уровни кэширования и копаться в оптимизации, чтобы еще больше снизить влияние на базу данных.