Pourquoi utiliser une variable locale au lieu d'une variable d'instance dans Session_Controller

Question

Ruby (et le framework Rails) est le premier nouveau langage de programmation que j'ai appris depuis l'obtention de mon diplôme en 1987; Donc, s'il vous plaît supporter avec un newbee virtuel sur cette question.

J'ai travaillé sur le très bon tutoriel de Michael Hartl, Learn Rails By Example. Après avoir traversé les 8 premiers chapitres relativement indemnes, j'ai atteint un barrage mental dans le chapitre 9. Je comprends la différence fondamentale entre les variables d'instance et les variables locales (à la fois dans Ruby et plus spécifiquement dans Rails). Mais, je ne comprends pas pourquoi Michael utilise la variable locale "user" dans son contrôleur de sessions plutôt que la variable d'instance "@user". Voir, par exemple, la méthode Create dans la liste 9.9 de http://railstutorial.org/chapters/sign-in-sign-out#top. Michael repose sur un module Sessions_helper pour effectuer l'affectation suivante: "@current_user = user", mais s'il avait utilisé une variable instances en premier lieu, aurait-il dû faire l'affectation du tout (en supposant que les instances les variables sont disponibles dans les contrôleurs, les vues et les aides)? Est-il allé avec la variable locale de sorte que dans le module d'aide qu'il pourrait redéfinir la méthode « current_user » pour être,

def CURRENT_USER

@current_user ||= user_from_remember_token 

fin

Il est probablement clair pour vous les gars que je Je patauge un peu ici. Quoi qu'il en soit, merci d'avance à tous ceux qui peuvent me diriger directement.

-Chuck

Answer 1

Tout d'abord, vous ne voulez pas définir une variable d'instance pour @user en ce qui concerne l'utilisateur de la session, car il peut entrer en conflit avec exemple des noms de variables à users_controller. C'est pourquoi le code d'authentification opte pour @current_user. L'utilisation de l'assistant comme moyen de rendre ces méthodes accessibles à la fois au contrôleur et à la vue est un peu déroutante pour commencer. Vous avez raison de dire qu'il l'a fait afin que l'assistant définisse (ou récupère s'il est déjà configuré) le @current_user. Selon la devise de Rails "contrôleurs skinny, gros modèles", l'auteur ne veut pas définir la logique d'authentification ou les aides à l'authentification dans le contrôleur, il choisit donc d'utiliser l'assistant pour le gérer. En outre, si vous définissez le @current_user dans la méthode de création, il est pratiquement inutile car le reste de votre application ne pourra pas utiliser @current_user. En utilisant le SessionHelper et en l'incluant dans le ApplicationController, le reste de l'application peut utiliser ces méthodes dans ses contrôleurs et vues. En résumé, il n'est pas nécessaire de faire de l'utilisateur une variable d'instance dans la méthode de création du contrôleur car le composant SessionHelper définit la variable d'instance qui peut être utilisée dans tous les contrôleurs (car elle est incluse dans ApplicationController). est dans l'application/helpers).

---

J'opte pour une autre solution:
définir une before_filter (il exécute à chaque requête) méthode dans le ApplicationController et comprennent son code de l'aide:

@current_user ||= user_from_remember_token 

puis dans les vues au lieu d'utiliser <% if signed_in? %>, j'utilise <% if @current_user %>

En utilisant le before_filter exécute ce code sur chaque demande pour chaque contrôleur, tandis que le tuto La méthode rial n'appelle le code de session que lorsque toute autre partie du code appelle current_user, ce que vous préférerez peut-être.

Mon approche élimine la nécessité de mettre ce genre de choses dans app/helpers/, qui à mon avis ne devrait être utilisé pour aider les vues .. mais bon, à chacun son propre ... Je viens de trouver cette approche plus facile à comprendre. Le tutoriel est très bon et fait un excellent travail de séparation dans MVC et DRYness et il n'y a aucune raison pour laquelle vous ne pouvez pas utiliser la méthode décrite dans le tutoriel.

---

Vous savez peut-être plus de cela, mais je pense que la chose la plus importante que vous pouvez apprendre de tout cela est qu'il devrait y avoir très peu de logique métier (en dehors de la logique de routage) dans le contrôleur. Le code de votre contrôleur doit définir des variables d'instance (ou appeler une méthode pour définir la session dans cet exemple particulier) et acheminer vers la vue appropriée. Vous pouvez utiliser des modèles (ou d'autres modules) pour faire tout le sale boulot afin de créer ce qui devrait être dans ces variables d'instance. Le contrôleur et ApplicationController vous donnent accès aux paramètres http et à la session et vous pouvez passer les params à vos gros modèles (puisque les modèles ne sont pas conscients des params) et ensuite vos modèles devraient faire l'essentiel du travail.