Guirec, c'est juste que DCI est pas adapté à Ruby parce qu'on a des alternatives comme celle que je présente qui sont tout aussi fonctionnelles, respectent le SRP et ne pètent pas les perfs donc même si il y a bcp
de bruit autour de la possibilité de faire du DCI avec extend, je ne vois pas trop l'intérêt de cette implémentation en dehors des fashion victims. Je suis d'accord que la performance est moins importante que la maintenabilité/facilité du code, du moins dans notre contexte mais je me dis qu'on peut faire d'une pierre deux coups ;) Bonne journée, Simon Courtois On Monday 3 June 2013 at 17:01, Guirec Corbel wrote: > Merci Simon, > > Personnellement, je ne crois pas que la performance soit vraiment un problème > dans une application web. Le temps d'un développeur est plus précieux que le > temps machine. Pour moi, le DCI est plus un problème architectural qu'un > problème de performance. Si j'avais un truc qui me permettait de faire un > code plus beau au dépend d'un peu de performance, je le ferais. Sauf si > l'application à un besoin spécifique ou si la performance est vraiment > réduite bien sur. > > > Le 3 juin 2013 10:48, Simon Courtois <[email protected] > (mailto:[email protected])> a écrit : > > Salut Guirec, > > > > J'ai donné un talk sur le sujet à Paris.rb, les slides sont ici > > http://www.slideshare.net/happynoff/ruby-and-dci > > > > Le gros souci du DCI version Ruby à base d'extend c'est que ça pose de gros > > soucis de performances. > > Chaque appel à extend vide le cache d'appel de méthodes de Ruby, de toute > > ton app ! :/ > > > > Le cache d'appel de méthodes c'est ce qui permet à Ruby de ne pas chercher > > comment appeler une > > méthode (envoyer un message, je sais) à chaque fois qu'il en a besoin. > > > > En clair, chaque fois que tu touches à la hiérarchie des classes dans ton > > script Ruby, le cache saute. > > Quand est-ce que ça arrive ? À chaque création de classe, module. À chaque > > appel à include, prepend ou extend. > > Il y a encore pas mal d'autres cas que je n'ai plus en tête. > > > > Quand tu appelles extend sur un objet pendant le runtime, ça change la > > hiérarchie de ton code et ça fait donc > > sauter le cache. Ça impacte donc _toute_ ton application ce qui est tout de > > même gênant. > > > > Je te conseille d'utiliser plutôt un objet spécifique qui utilise la > > délégation (tu en trouveras un exemple dans mes slides). > > > > Bonne journée :) > > > > Simon Courtois > > > > > > On Monday 3 June 2013 at 16:40, Guirec Corbel wrote: > > > > > > > > > Bonjour à tous, > > > > > > J'ai lu quelques trucs à propos du DCI (Data Context Integration) et je > > > ne sais pas quoi en penser. J'aimerais avoir votre avis sur la question. > > > > > > Pour ceux qui ne connaissent pas, je vous conseil de lire ceci : > > > http://mikepackdev.com/blog_posts/24-the-right-way-to-code-dci-in-ruby. > > > > > > J'aime bien le concept de rôle. Dans l'application que je fais j'ai des > > > utilisateurs et un type d’utilisateur spécial, le collectionneur. Si j'ai > > > bien compris le concept il faut écrire un role comme ceci : > > > > > > module CollectorRole > > > def paintings > > > Painting.where(user_id: self.id (http://self.id)) > > > end > > > end > > > > > > Et pour avoir toutes les peintures d'un collectionneur je pourrais faire > > > ceci : > > > > > > user = User.new > > > user.extend CollectorRole > > > user.paintings > > > > > > Je n'aurais donc que deux modèles minimaux, User et Painting, > > > représentant uniquement les données (présente dans la base donnée). Si je > > > veux ajouter un comportement à mon utilisateur je l'ajouterai dans un > > > rôle. Je respect donc plus facilement le SRP (Single Responsability > > > Principle). Ça remplace un héritage. > > > > > > Là ou j'ai du mal c'est au niveau du context et du contrôleur. Un exemple > > > qui fonctionne pas trop mal serait dans le cas ou je voudrais faire une > > > fonctionnalité qui permet aux utilisateurs de contacter les > > > collectionneurs. Je ferais un truc du genre : > > > > > > class UserContactCollectorContext > > > attr_reader :user_from, user_to > > > > > > def self.call(user_from, user_to) > > > UserContactCollectorContext.new(user_from, user_to).call > > > end > > > > > > def initialize(user_from, user_to) > > > @user_from, @user_to = user_from, user_to > > > @user_to.extend CollectorRole > > > end > > > > > > def call > > > @paintings = @user_to.paintings > > > # traitement et envoi du mail > > > end > > > end > > > > > > Et dans mon contrôleur j'aurais ceci : > > > > > > class MessagesController < ApplicationController > > > def send_message_to_collector > > > UserContactCollectorContext.call(User.find(params[:user_from]), > > > User.find(params[:user_to])) end > > > end > > > > > > Ce code me convient. Là ou ça ne me convient pas c'est quand je veux tout > > > simplement la liste des utilisateurs. Il faudrait faire un contrôleur du > > > genre : > > > > > > class UsersController < ApplicationController > > > def index > > > @users = UserAllContext.call > > > end > > > end > > > > > > Il y a un exemple similaire ici : > > > https://github.com/randx/rails-dci-example/blob/master/app/controllers/documents_controller.rb > > > > > > Franchement, créé un context pour chaque action de ce type je trouve que > > > c'est trop. C'est plus simple de faire "@users = User.all". L'avantage > > > c'est que ça sépare vraiment la logique. Le contrôleur n'a pas à savoir > > > ce que fait le context. S'il y a un mail envoyé, un géocodage ou tout le > > > reste, le contrôleur ne le sait pas. C'est vraie pour l'inverse. Le > > > context ne sait pas ce que fait le contrôleur. On a donc un séparation > > > franche entre la logique métier et la partie système. > > > > > > J'ai lu le livre CleanRuby. Je penses que Jim Gay va trop loin. Il créé > > > un context "framework agnostic" qui appel des fonctions du contrôleur. > > > J'ai du mal à comprendre pourquoi il écrit un livre prônant la valeur du > > > "Skinny Controller" alors qu'il a du code comme ceci : > > > https://github.com/radiant/radiant/blob/master/app/models/page.rb. > > > > > > Qu'en pensez-vous? Est-ce que quelqu'un d'entre vous à mis en pratique ce > > > concept? Quels sont vos impressions? > > > > > > Merci à tous! > > > -- > > > -- > > > Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" > > > de Google Groups. > > > Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse > > > [email protected] (mailto:[email protected]) > > > Pour résilier votre abonnement envoyez un e-mail à l'adresse > > > [email protected] > > > (mailto:[email protected]) > > > --- > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes > > > Railsfrance. > > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le > > > concernant, envoyez un e-mail à l'adresse > > > [email protected] > > > (mailto:[email protected]). > > > Pour plus d'options, visitez le site > > > https://groups.google.com/groups/opt_out . > > > > > > > > > > -- > > -- > > Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de > > Google Groups. > > Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse > > [email protected] (mailto:[email protected]) > > Pour résilier votre abonnement envoyez un e-mail à l'adresse > > [email protected] > > (mailto:[email protected]) > > --- > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes > > Railsfrance. > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le > > concernant, envoyez un e-mail à l'adresse > > [email protected] > > (mailto:railsfrance%[email protected]). > > Pour plus d'options, visitez le site > > https://groups.google.com/groups/opt_out . > > > > > > -- > -- > Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de > Google Groups. > Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse > [email protected] (mailto:[email protected]) > Pour résilier votre abonnement envoyez un e-mail à l'adresse > [email protected] > (mailto:[email protected]) > --- > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes > Railsfrance. > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le > concernant, envoyez un e-mail à l'adresse > [email protected] > (mailto:[email protected]). > Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out > . > > -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance. Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse [email protected]. Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
