Est-ce que quelqu'un utilise ici DTO pour transférer des données du contrôleur à la vue? Si oui, où recommanderiez-vous stocker ces fichiers? / Applications / DTO, puis laissez-les refléter la structure de vues dir? Toute recommandation sur tester ces animaux avec RSPEC?
4 Réponses :
Si vous venez d'un arrière-plan .NET ou J2EE, vous pensez peut-être des modèles comme DTO. Vous pouvez ou non être surpris (et éventuellement heureux) d'apprendre que les rails ne font pas de choses de cette façon par convention.
En particulier, il n'est pas nécessaire de transférer formellement des objets sérialisés entre les contrôleurs et les vues. Les variables d'instance (les valeurs d'attribut de modèle généralement) créées dans le contrôleur sont disponibles dans la vue gratuitement fournies par le cadre sans aucun effort de programmation supplémentaire nécessaire.
Ce que j'ai dit est qu'en général, c'est un travail qui est géré par des "assistants". Ils vous aident fondamentalement à formater vos objets de modèle pour la vision de la consommation de la vue. Il n'est donc certainement pas une cartographie 1-1 de concepts, mais c'est la pensée dans le monde des rails
La convention Rails ne doit pas utiliser de niveaux distribués pour contrôleur et afficher les couches. La séparation est là, mais elle est logique et relativement mince / légère par rapport aux types de cadres que vous voyez dans Java Terre.
L'architecture de base est que le contrôleur définit les variables d'instance disponibles dans la vue correspondante. Dans le cas général, les variables d'instance seront des cas de modèle ou des collections d'instances de modèle (provenant de la base de données). Les modèles doivent être au cœur de votre logique commerciale. Les contrôleurs coordonnent les flux de données. Vues affichez-la. Les aides sont utilisés pour formater des valeurs d'affichage dans la vue ... tout ce qui prend une valeur de modèle et fait quelque chose juste à des fins d'affichage (vous constaterez peut-être qu'une méthode d'assistance utilisée à plusieurs reprises peut être mieux sur le modèle lui-même).
Toutefois, si vous constatez qu'une vue a besoin de connaissances de nombreux modèles différents, vous pouvez trouver plus facile d'envelopper des modèles dans un autre objet à un niveau d'abstraction plus élevé. Rien ne vous empêche de créer des objets non actifs-enregistrés qui collectent et coordonnent vos modèles AR réels. Vous pouvez ensuite instancier ces objets dans le contrôleur et les faire offrir à la vue. Vous devez généralement être à un niveau de complexité assez dense dans le contrôleur pour avoir besoin de ce type de chose.
J'aurais tendance à jeter de tels objets dans les applications / modèles - Les rails chargent déjà tout dans ce répertoire, empêche les choses d'un point de vue de configuration / attente.
Merci à ça. Cela va prendre un peu d'habitude, mais je vois un peu la pensée. J'apprécie la réponse bien articulée.
S'il vous plaît ne pas écouter les autres réponses. Ils sont terribles. Les aides sur rails sont terribles. Utiliser des modèles de rails partout est terrible. Je vous demande, concevez votre application correctement et décidez si vous avez besoin de DTO ou non. Décidez si vous souhaitez réellement avoir des modèles de rails pour gérer des objets autres que la communication avec la base de données. Décidez si vous ne voulez pas avoir de couche entre votre application et vos rails et ainsi de suite. Les Rails Design convient à seulement de petites applications ou d'applications qui doivent être développées super rapidement. Mais si ce n'est pas quelque chose de trivial et que vous vous attendez à le développer pendant un certain temps, veuillez investir votre temps dans une conception appropriée. N'ayez pas peur de casser les commodités des rails. Et que la force avec vous.