Quelqu'un utilise-t-il ici des DTO pour transférer des données du contrôleur vers la vue? Si oui, où recommanderiez-vous de stocker ces fichiers?/apps/dtos, puis laissez-les refléter la structure dir de vues? Des recommandations sur le test de ces animaux avec rspec?ruby on Rails dto objects - Où les stockez-vous?
La convention Rails est de ne pas utiliser les niveaux distribués pour les couches de contrôleur et d'affichage. La séparation est là, mais elle est logique et relativement mince/légère par rapport aux types de frameworks que vous voyez en Java.
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 instances 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 métier. Les contrôleurs coordonnent les flux de données. Les vues l'affichent. Les assistants sont utilisés pour formater les 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 pouvez trouver qu'une méthode d'assistance utilisée à plusieurs reprises peut être mieux sur le modèle lui-même).
Cependant, si vous trouvez qu'une vue a besoin de connaissances de nombreux modèles différents, vous trouverez peut-être plus facile pour envelopper les modèles dans un autre objet à un niveau plus élevé d'abstraction. Rien ne vous empêche de créer des objets non actifs qui collectent et coordonnent vos modèles AR réels. Vous pouvez ensuite instancier ces objets dans le contrôleur et les mettre à la disposition de la vue. Vous devez généralement être à un niveau de complexité assez dense dans le contrôleur pour avoir besoin de ce genre de chose.
je aurais tendance à jeter ces objets dans les applications/modèles - Rails charges déjà tout dans ce répertoire, garde les choses faciles d'un point de vue config/attente.
Si vous venez d'un arrière-plan .NET ou J2EE, vous pensez peut-être à des modèles tels que DTO. Vous pouvez ou non être surpris (et peut-être heureux) d'apprendre que Rails ne fait pas les choses de cette façon par convention.
En particulier, il n'est pas du tout nécessaire de transférer formellement (ou stocker) des objets sérialisés entre les contrôleurs et les vues. Les variables d'instance (généralement les valeurs d'attribut de modèle) créées dans le contrôleur sont disponibles gratuitement dans la vue, comme le prévoit le framework, sans effort de programmation supplémentaire.
Ce qu'on m'a dit c'est qu'en général, c'est un travail qui est géré par des «aides». Ils vous aident essentiellement à formater vos objets de modèle pour la consommation de vue à partir de la vue. Il est donc certainement pas une mise en correspondance de concepts 1-1, mais c'est la pensée dans les rails monde
Veuillez ne pas écouter les autres réponses. Ils sont terribles. Les aides de Rails sont terribles. L'utilisation de modèles de rails partout est terrible. Je vous en supplie, concevez votre application correctement et décidez si vous avez besoin de DTO ou non. Décidez si vous voulez réellement avoir des modèles de rails pour gérer d'autres choses que la communication avec la base de données. Décidez si vous voulez réellement ne pas avoir de couche entre votre application et les rails et ainsi de suite. La conception de Rails est adaptée uniquement aux petites applications ou applications qui doivent être développées très rapidement. Mais si ce n'est pas quelque chose d'anodin et que vous prévoyez de le développer pendant un certain temps, s'il vous plaît investir votre temps dans la conception appropriée. N'ayez pas peur de casser les commodités de Rails. Et puisse la force avec toi.
Merci Toby. Ça va prendre un peu de temps pour s'y habituer, mais je vois un peu la pensée. J'apprécie la réponse bien articulée. –