Зачем использовать локальную переменную вместо переменной экземпляра внутри Session_Controller - PullRequest
0 голосов
/ 12 ноября 2010

Ruby (и фреймворк Rails) - это первый новый язык программирования, который я выучил с тех пор, как окончил со степенью CS в 1987 году; поэтому, пожалуйста, имейте с этим виртуального новичка.

Я работал над действительно превосходным учебным пособием Майкла Хартла «Изучите Rails By Example». Пройдя первые 8 глав, оставаясь относительно невредимыми, я столкнулся с умственным препятствием в главе 9. Я понимаю основное различие между переменными экземпляра и локальными переменными (как в Ruby, так и, более конкретно, в Rails). Но я не понимаю, почему Майкл использует локальную переменную «пользователь» в своем контроллере сеансов, а не переменную экземпляра «@user». См., Например, метод Create в листинге 9.9 из http://railstutorial.org/chapters/sign-in-sign-out#top.

Майкл полагается на модуль Sessions_helper для выполнения следующего назначения: "@current_user = user", но если бы он вообще использовал переменную instance, он бы вообще должен был выполнить назначение (при условии, что переменные экземпляров) доступны в контроллерах, представлениях и помощниках)? Он пошел с локальной переменной, чтобы в вспомогательном модуле он мог переопределить метод «current_user», чтобы он был

def current_user

@current_user ||= user_from_remember_token

конец

Вероятно, вам, ребята, ясно, что я немного колеблюсь здесь. В любом случае, заранее спасибо всем, кто может направить меня прямо.

-Chuck

1 Ответ

0 голосов
/ 12 ноября 2010

Во-первых, вы не хотите устанавливать переменную экземпляра для @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-параметрам и сеансу, и вы можете передавать параметры в ваши толстые модели (поскольку модели не знают о параметрах), а затем ваши модели должны выполнять основную часть работы.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...