Modèle, vue, contrôleur et assistant Rails :qu'est-ce qui va où ?
https://stackoverflow.com/questions/60658
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Dans le développement Ruby on Rails (ou MVC en général), quelle règle rapide dois-je suivre pour savoir où placer la logique.
Merci de répondre par l'affirmative - Avec Mets ça ici, plutôt que Ne mets pas ça là.
La solution
MVC
Manette:Mettez ici le code qui consiste à déterminer ce que veut un utilisateur, à décider quoi lui donner, à déterminer s'il est connecté, s'il doit voir certaines données, etc.En fin de compte, le contrôleur examine les demandes et détermine quelles données (modèles) afficher et quelles vues restituer.Si vous avez des doutes quant à savoir si le code doit être inséré dans le contrôleur, ce ne devrait probablement pas être le cas.Gardez vos contrôleurs maigre.
Voir:La vue ne doit contenir que le minimum de code pour afficher vos données (modèle), elle ne doit pas effectuer beaucoup de traitements ou de calculs, elle doit afficher des données calculées (ou résumées) par le modèle ou générées à partir du contrôleur.Si votre vue a vraiment besoin d'effectuer un traitement qui ne peut pas être effectué par le modèle ou le contrôleur, placez le code dans un assistant.Beaucoup de code Ruby dans une vue rend le balisage des pages difficile à lire.
Modèle:Votre modèle devrait être là où tous votre code qui concerne vos données (les entités qui composent votre site par ex.Utilisateurs, Postes, Comptes, Amis, etc.) vit.Si le code doit enregistrer, mettre à jour ou résumer les données liées à vos entités, placez-le ici.Il sera réutilisable dans vos vues et contrôleurs.
Autres conseils
Pour ajouter à la réponse de pauliephonic :
Assistant:fonctions pour faciliter la création de la vue.Par exemple, si vous parcourez toujours une liste de widgets pour afficher leur prix, placez-la dans un assistant (avec un partiel pour l'affichage réel).Ou si vous avez un morceau de RJS que vous ne voulez pas encombrer la vue, placez-le dans un assistant.
Le modèle MVC ne concerne en réalité que l’interface utilisateur et rien d’autre.Vous ne devez pas mettre de logique métier complexe dans le contrôleur car il contrôle la vue mais pas la logique.Le contrôleur doit se soucier de sélectionner la vue appropriée et déléguer des éléments plus complexes au modèle de domaine (Modèle) ou à la couche métier.
Domain Driven Design a un concept de services qui est un endroit où vous collez une logique qui doit orchestrer un certain nombre de différents types d'objets, ce qui signifie généralement une logique qui n'appartient pas naturellement à une classe Model.
Je considère généralement la couche Service comme l'API de mes applications.Mes couches de services correspondent généralement assez étroitement aux exigences de l'application que je crée. La couche de service agit donc comme une simplification des interactions plus complexes trouvées dans les niveaux inférieurs de mon application, c'est-à-direvous pourriez atteindre le même objectif en contournant les couches de service, mais vous devrez actionner beaucoup plus de leviers pour que cela fonctionne.
Notez que je ne parle pas ici de Rails, je parle d'un style architectural général qui répond à votre problème particulier.
Des explications parfaites ici déjà, une phrase très simple en guise de conclusion et facile à retenir :
Nous avons besoin de modèles SMART, de contrôleurs THIN et de vues DUMB.
La méthode Rails est d'avoir contrôleurs maigres et gros modèles.
Mettez les éléments liés à l'autorisation/au contrôle d'accès dans le contrôleur.
Les modèles concernent uniquement vos données.Validation, Relations, CRUD, Logique Métier
Les vues consistent à afficher vos données.Afficher et obtenir des entrées uniquement.
Les contrôleurs visent à contrôler quelles données passent de votre modèle à votre vue (et quelle vue) et de votre vue à votre modèle.Les contrôleurs peuvent également exister sans modèles.
J'aime considérer le contrôleur comme un agent de sécurité/réceptionniste qui vous dirige, le client (demande), vers le comptoir approprié où vous posez (visualisez) une question à un caissier.Le caissier (vue) va alors chercher la réponse auprès d'un manager (modèle), que l'on ne voit jamais.Vous faites la demande, puis retournez voir l'agent de sécurité/réceptionniste (contrôleur) et attendez que l'on vous demande d'aller vers un autre caissier (vue) qui vous donne la réponse que le responsable (modèle) leur a donnée en réponse à la question de l'autre caissier (vue). .
De même, si vous souhaitez dire quelque chose au caissier (voir), la même chose se produit, sauf que le deuxième caissier vous dira si le responsable a accepté vos informations.Il est également possible que l'agent de sécurité/réceptionniste (contrôleur) vous ait demandé de faire une randonnée puisque vous n'étiez pas autorisé à communiquer cette information au responsable.
Donc, pour prolonger la métaphore, dans mon monde stéréotypé et irréaliste, les caissiers (opinions) sont jolis mais la tête vide et croient souvent tout ce que vous leur dites, les agents de sécurité/réceptionnistes sont peu polis mais ne sont pas très compétents mais ils savent où les gens devraient et ne devrait pas y aller et les managers sont vraiment laids et méchants mais savent tout et peuvent dire ce qui est vrai et ce qui ne l'est pas.
Une chose qui aide à séparer correctement est d'éviter l'anti-modèle "passer les variables locales du contrôleur à la vue".Au lieu de cela:
# app/controllers/foos_controller.rb:
class FoosController < ApplicationController
def show
@foo = Foo.find(...)
end
end
#app/views/foos/show.html.erb:
...
<%= @foo.bar %>
...
Essayez de le déplacer vers un getter disponible comme méthode d'assistance :
# app/controllers/foos_controller.rb:
class FoosController < ApplicationController
helper_method :foo
def show
end
protected
def foo
@foo ||= Foo.find(...)
end
end
#app/views/foos/show.html.erb:
...
<%= foo.bar %>
...
Cela facilite la modification de ce qui est mis dans "@foo" et de la manière dont il est utilisé.Cela augmente la séparation entre le contrôleur et la vue sans les compliquer davantage.
Eh bien, cela dépend en quelque sorte de ce à quoi la logique doit faire face...
Souvent, il est logique d’intégrer davantage d’éléments dans vos modèles, en laissant les contrôleurs petits.Cela garantit que cette logique peut facilement être utilisée depuis n'importe quel endroit où vous avez besoin d'accéder aux données que représente votre modèle.Les vues ne doivent contenir presque aucune logique.Donc vraiment, en général, vous devriez vous efforcer de faire en sorte que vous ne vous répétiez pas.
En outre, une recherche rapide sur Google révèle quelques exemples plus concrets de ce qui se passe où.
Modèle:les exigences de validation, les relations entre les données, la création de méthodes, la mise à jour des méthodes, la destruction des méthodes, la recherche de méthodes (notez que vous devriez avoir non seulement les versions génériques de ces méthodes, mais s'il y a quelque chose que vous faites beaucoup, comme rechercher des personnes aux cheveux roux en nom de famille, alors vous devez extraire cette logique pour que tout ce que vous ayez à faire soit d'appeler find_redH_by_name("smith") ou quelque chose comme ça)
Voir:Il devrait s'agir uniquement de formatage des données, et non de leur traitement.
Manette:C'est là que va le traitement des données.Depuis Internet :"Le but du contrôleur est de répondre à l'action demandée par l'utilisateur, de prendre tous les paramètres définis par l'utilisateur, de traiter les données, d'interagir avec le modèle, puis de transmettre les données demandées, sous leur forme finale, à la vue."
J'espère que cela pourra aider.
En termes simples, en général,Des modèles aura tous les codes liés aux tables, leurs relations simples ou complexes (pensez-les comme des requêtes SQL impliquant plusieurs tables), la manipulation des données/variables pour arriver à un résultat en utilisant la logique métier.
Contrôleurs aura du code/des pointeurs vers les modèles pertinents pour le travail demandé.
Vues acceptera l'entrée/l'interaction de l'utilisateur et affichera la réponse résultante.
Tout écart majeur par rapport à ces éléments exercera une pression indésirable sur cette partie et les performances globales de l’application pourraient en être affectées.
Tests, tests...Mettez autant de logique que possible dans le modèle et vous pourrez alors le tester correctement.Les tests unitaires testent les données et la manière dont elles sont formées en testant le modèle, et les tests fonctionnels testent la manière dont elles sont acheminées ou contrôlées en testant les contrôleurs. Il s'ensuit donc que vous ne pouvez pas tester l'intégrité des données à moins qu'elles ne soient dans le modèle.
j
