Salut à tous,
J'ai changé le mode de fonctionnement d'un service. Voici le commit :
https://github.com/GCorbel/lescollectionneursassocies/commit/91ff3ca7ebf35903491b0a37c08d377ddc62dc52.
Plutôt que d'avoir un contrôleur qui parle au form et au service ainsi
que le service qui parle au form, j'ai un contrôleur qui parle au form
et un form qui parle au service. L'avantage que je vois est que le
contrôleur parle au form exactement comme avec un modèle ActiveRecord.
Qu'en pensez-vous? Trouvez vous que le code est plus propre avant qu'après?
Bonne journée!
Le 2014-04-02 08:15, Guirec Corbel a écrit :
Regarde cette article :
http://robots.thoughtbot.com/activemodel-form-objects. À la fin il y a
un exemple ou tu vois qu'il envoi des courriels, il fait ces logs,
etc... T'en pense quoi?
Le 2 avril 2014 06:47, Florian Dutey <fdu...@gmail.com
<mailto:fdu...@gmail.com>> a écrit :
Si je me base sur mon experience Java, un service devrait etre
appele comme ceci:
dummy_object_service.save(dummy_object)
Il n'y a aucune raison qu'une instance de service soit liee a une
instance d'un objet en particulier
Ton form est la pour valider ton modele, il ne devrait pas faire
la sauvegarde
Donc, a mon sens, tu devrais avoir un truc du genre
form = UserForm.new(params[:user])
if form.valid?
# static
UserService.save(form.object)
# instance
UserService.get.save(form.object)
end
static ou instance... je ne le sais... je sais pas comment se
comportent les services en ruby
Je trouve tres bizarre le concept d'un service qui sauve un form,
un service devrait toujours travailler sur les objets qu'il est
cense manager, pas leur form (genre pour le delete, tu crees un
form que tu files au service?)
=====
ou est-ce le formulaire ou le service devrait savoir comment créer
les associations. Est-ce le rôle d'un autre type d'objet?
C'est difficile de se retrouver dans ces concepts.
Bienvenue dans l'enfer des services qui doivent appeler d'autres
services (surtout si il y a du IOC par dessus) et qui transforment
la soit disant super reusabilite de tout ca en un sac de noeuds
insupportable.
Mais dans ton exemple super simple, je ferais tout simplement:
def user
group.users.new # or find
end
Et si tu veux ajouter un user existant a un groupe existant, alors
tu ne travailles plus sur une isntance de user ou group mais sur
une instance de l'association entre les 2
Donc ton form et ton service a utiliser doivent etre ceux de
l'association.
Le 1 avril 2014 17:22, Guirec Corbel <guirec.cor...@gmail.com
<mailto:guirec.cor...@gmail.com>> a écrit :
Bonjour à tous,
J'aimerai avoir votre opinion sur le rôle des form objects,
services objects et du controller. À votre avis, est-ce le
form object qui va créer un service et l'appeler ou est-ce que
le controller doit créer un service avec le form object en
paramêtre? Je m'explique avec du code :
Est-ce que ça doit être ça :
class MyController < ApplicationController
def create
MyForm.new(params).save
end
end
class MyForm
def save
Service.new(self).save
end
end
ou
class MyController < ApplicationController
def create
form = MyForm.new(params)
Service.new(form).save
end
end
Autre question : Est-ce le rôle du controller de construire
les modèle ou à l'un des deux autres. Imaginons un formulaire
de création d'utilisateur avec un groupe. Est-ce que le "bon"
code serait comme ceci :
class MyController < ApplicationController
def create
form = MyForm.new(user: user, group: group)
form.attributes = params[:user]
form.save
end
def user
User.new # or find
end
def group
Group.find(params[:group_id])
end
end
ou est-ce le formulaire ou le service devrait savoir comment
créer les associations. Est-ce le rôle d'un autre type d'objet?
C'est difficile de se retrouver dans ces concepts.
--
--
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 railsfrance@googlegroups.com
<mailto:railsfrance@googlegroups.com>
Pour résilier votre abonnement envoyez un e-mail à l'adresse
railsfrance-unsubscr...@googlegroups.com
<mailto:railsfrance-unsubscr...@googlegroups.com>
--- 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
railsfrance+unsubscr...@googlegroups.com
<mailto:railsfrance%2bunsubscr...@googlegroups.com>.
Pour plus d'options, visitez le site
https://groups.google.com/d/optout .
--
--
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 railsfrance@googlegroups.com
<mailto:railsfrance@googlegroups.com>
Pour résilier votre abonnement envoyez un e-mail à l'adresse
railsfrance-unsubscr...@googlegroups.com
<mailto:railsfrance-unsubscr...@googlegroups.com>
---
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
railsfrance+unsubscr...@googlegroups.com
<mailto:railsfrance+unsubscr...@googlegroups.com>.
Pour obtenir davantage d'options, consultez la page
https://groups.google.com/d/optout.
--
--
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
railsfrance@googlegroups.com
Pour résilier votre abonnement envoyez un e-mail à l'adresse
railsfrance-unsubscr...@googlegroups.com
---
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 railsfrance+unsubscr...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/d/optout .
