Во-первых, вы не хотите устанавливать переменную экземпляра для @user
в отношении пользователя сеанса, потому что он может конфликтовать с именами переменных экземпляра в users_controller.Вот почему код аутентификации выбирает @current_user
.
. Использование помощника в качестве средства, позволяющего сделать эти методы доступными как для контроллера, так и для представления, с самого начала немного сбивает с толку.Вы правы в том, что он сделал это, чтобы помощник установил (или восстановил, если он уже установлен) @current_user
.Следуя девизу Rails «тощие контроллеры, толстые модели», писатель не хочет определять какую-либо логику аутентификации или помощников аутентификации в контроллере, поэтому он решает использовать помощника для его обработки.Кроме того, если вы установите @current_user
в методе создания, это в значительной степени бесполезно, поскольку остальная часть вашего приложения не сможет использовать @current_user
.Использование SessionHelper
и включение его в ApplicationController
позволяет остальной части приложения использовать эти методы в своих контроллерах и представлениях.Короче говоря, нет необходимости делать пользователя переменной экземпляра в методе создания контроллера, потому что SessionHelper устанавливает переменную экземпляра, которая может использоваться во всех контроллерах (потому что это было включено в ApplicationController), и во всех представлениях (потому что этонаходится в приложении / помощниках).
Я выбрал другое решение:
определил before_filter
(так он выполняется при каждом запросе) метод в ApplicationController
и включил его код изпомощник:
@current_user ||= user_from_remember_token
затем в представлениях вместо <% if signed_in? %>
я использую <% if @current_user %>
Использование before_filter выполняет этот код при каждом запросе для каждого контроллера, в то время как учебникМетод вызывает код сеанса только тогда, когда любая другая часть кода вызывает current_user
, что вы можете предпочесть.
Мой подход исключает необходимость помещать этот материал в app/helpers/
, что, по моему мнению, должно быть толькоиспользуется для помощи взглядам .. но эй, каждому свое ... я просто нахожу этот подход проще для понимания.Учебное пособие очень хорошее и отлично справляется с разделением в MVC и DRYness, и нет никаких причин, почему вы не можете использовать метод, описанный в учебном пособии.
Вы, возможно, уже знаете большую часть этого, но я думаю, что самая важная вещь, которую вы можете извлечь из этого, - это то, что в контроллере должно быть очень мало бизнес-логики (кроме логики маршрутизации).Код в вашем контроллере должен установить переменные экземпляра (или вызвать метод для установки сеанса в этом конкретном примере) и направить к соответствующему представлению.Вы можете использовать модели (или другие модули), чтобы выполнить всю грязную работу, чтобы создать то, что должно быть в этих переменных экземпляра.Контроллер и ApplicationController предоставляют вам доступ к http-параметрам и сеансу, и вы можете передавать параметры в ваши толстые модели (поскольку модели не знают о параметрах), а затем ваши модели должны выполнять основную часть работы.