au dela du troll, je comprends tres bien les arguments de pas "tout foutre dans le modele". pour ma part, jai tendance a extraire au maximum dans des modules par semantique et a faire des shared examples pour tester. c vrai quau final, mes modeles ont 2 millions de methodes.... dans ce cas la, je prefere decouper mes modeles et les linkers avec des has one (on parle de rails/active record uniquement).
je connais les arguments pour les services et pour les forms. ils sont tout a fait justifies. en particuliee sur les services, qui veut qu'un objet n'ait pas a porter la responsabilite de sa serialisation. certes, si tes classes metier ont vocation a etre reutilisees dans autre chose que des projets rails, c plus vers ca quil faut sorienter. par contre, le fait qu'un modele ne porte pas ses validations, je trouve ca moisi. un User a forcement un nom de famille, quel que soit le projet dans lequel tu lutilises. ca fait partie du metier du User et pas de son form. si tu reutilises beaucoup ton code, je trouve ca useless de devoir reimplementer les validations a chaque fois. "ben tu inclus aussi le form" me diras tu. oui mais dans ce cas la, si un dev oublie de lutiliser, il peut sauver un objet invalide. c'est dommage. enfin, quand tu adoptes la strategie form / service / dao (ben oui, on decouple ou pas mais on fait pas les choses a moitie :p), tes modeles sont juste des objets completement vides. acceder aux relations est un enfer, tu ne sais jamais si elles sont loades ou pas (ce qui peut leader a persister du data complement inconsistent, si tu fais du counter cache). les mecs d'hibernate ont resolu ca en foutant des proxys sur les associations, ce qui veut dire que..... le modele a "conscience" d'etre persiste en sql et n'est plus juste un simple conteneur comme le dit le paradigme... bon, apres je connais plein de gens qui sont tres heureux de cette convention. et ils ont des tonnes darguments tres valables. (et hibernate, ca scale sa vieille maman :D). mais comme tu peux le constater, jen ai dautres :p. mais vu quon parle technique, ya pas de "vraie solution" ou de "fausse". les deux ont des vrais avantages (et de vrais iconvenients aussi). c'est une question de contexte et de gouts personels. en ce qui me concerne, tant que je reste eloigne de ces cochonneries de services et de form, je suis le plus heureux du monde haha. Le mardi 4 mars 2014, Simon Courtois <[email protected]> a écrit : > Je pensais juste au fait d'avoir une option/instruction qui dit de prendre en compte les validations du modèle > > lors de la validation. > > Dans mon cas c'était un peu plus compliqué parce que j'avais une association à valider qui était celle contenant > > les validations Devise mais en gros j'avais cette méthode dans mon FormObject: > > def valid? > > [super, account.valid?].reduce(:&) > > end > > Simon Courtois > > On 4 mars 2014 at 12:27:00, Guirec Corbel ([email protected]) wrote: > > @simon, merci pour tes idées. Je vais regarder à pour les dates. Pour la validation des modèles tu veux dire que le form objet ferais une réflection des validations des modèles si jamais il y en a certaines manquantes dans le form. Par exemple, si on un form comme ceci: > > class Form > include ActiveForm::Form > include ActiveForm::ValidationReflector > properties :username, on: :user > self.main_model = :user > end > > et un modèle comme ceci: > > class User < ActiveRecord::Base > validates :username, precense: true > end > > il faudrait que form.valid? retourne false et remplissent les erreurs du modèle. C'est ça? > > Ça semble être une bonne idée. Je suis effectivement intéressé par le code que tu as fait. > > > > @florian, Je pense qu'il a certain conceptes qu'il ne faut pas oublier dans les autres languages. Mettre tout dans le modèle fait qu'il devient difficile à tester. De plus, séparer les responsabilités permet une meilleure réutilisation des objets ainsi qu'une meilleur maintenabilité. Je suis très heureux d'utiliser ces conceptes. > > Bye! > > Le 2014-03-04 04:17, Florian Dutey a écrit : > > Je viens de jeter un coup d'oeil a la gem, je vous vois parler de ServiceObjects, de FormObjects... Vous seriez pas plus heureux a faire de la J2EE, voire meme du ZendFramework? :o > /troll > > Le 4 mars 2014 17:02, Simon Courtois <[email protected]> a écrit : > > Salut Guirec, > J'ai pas encore eu l'occasion de tester ta gem mais je peux déjà te donner deux > points sur lesquels j'ai galéré avec Reform et dont tu peux tenir compte si tu le veux :) > 1. Gestion des champs date. La conversion des champs de type date_select est faite très proche > de ActiveRecord et du coup on la considère souvent comme acquise mais en général avec les > FormObjects ce n'est pas pris en compte et ne marche pas. > 2. Permettre de facilement appeler les validation des modèles si on le souhaite. Cas pratique, un form > d'inscription qui tape sur Devise. Quand le modèle implemente :validatable ça peut être sympa de pouvoir > facilement appeler ces validations en plus de celles du FormObject. Je pourrais te ressortir le code que j'ai > utilisé pour faire marcher ça avec Reform ;) > En tout cas merci pour tes efforts, c'est cool :) > Simon Courtois > > On 4 mars 2014 at 09:49:34, Florian Dutey ([email protected]) wrote: -- -- 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 .
