j'ai besoin d'injecter un service basé sur la propriété de domaine, jusqu'à présent je suis venu avec ce qui suit:Grails: Dynamiquement injectent le service en classe de domaine
ApplicationHolder.application.getServiceClass("package.${property}Service").clazz
mais le chargement de cette façon ne pas injecter par ses services dépendants . Est-ce que je le fais mal?
Les nouvelles instances contournent la gestion des dépendances de Spring; vous devez obtenir le bean singleton configuré à partir du contexte de l'application. Utilisez ceci:
def service = ApplicationHolder.application.getMainContext().getBean("${property}Service")
Cela suppose que la « propriété » est le nom de haricot partiel pour un service, à savoir pour FooBarService, la propriété devrait être « foobar ». Si c'est « foobar » vous pouvez utiliser GrailsNameUtils.getPropertyName() pour le fixer:
import grails.util.GrailsNameUtils
String beanName = GrailsNameUtils.getPropertyName(property) + 'Service'
def service = ApplicationHolder.application.getMainContext().getBean(beanName)
Oui. Les services ne sont pas injectés dans les objets de domaine. Si votre objet de domaine a besoin de quelque chose pour un cas d'utilisation particulier, laissez le service qui possède ce cas d'utilisation appeler l'autre service au nom de l'objet de domaine.
Tout bean Spring peut être injecté dans des classes de domaine comme dans les contrôleurs, c'est-à-dire "def fooService". Le cas d'utilisation courant est d'appeler un service dans un validateur personnalisé. –
Peut être; Je ne suis tout simplement pas d'accord avec le fait que cela devrait l'être. Un validateur est différent d'un objet de domaine comme un compte ou une personne. C'est un cas d'utilisation complètement différent. – duffymo
classes de domaine IMHO ne doivent pas contenir une logique du tout (à part les former validateurs).
Dans mes projets, je crée normalement un service pour chaque classe de domaine (par exemple de UserService pour la classe utilisateur) et je colle toute la logique là-dedans, même des petits morceaux en morceaux qui seraient normalement dans la classe de domaine.
Je pense que beaucoup de programmeurs venant du monde Java/C++ ont tendance à trouver ça moche, mais ça convient mieux à l'architecture Grails.
Il est vrai que les classes de domaine Grails ne sont pas vraiment adaptés à la logique, mais c'est dommage car je suis d'accord avec Fowler sur celui-ci: http://en.wikipedia.org/wiki/Anemic_Domain_Model – Kimble
, Eric Evans a probablement senti une perturbation dans la force, quand quelqu'un dit que "les classes de domaine ne devraient pas contenir de logique du tout". Cela sonne comme un anti-pattern d'objet de domaine et est complètement à l'opposé de la conception dirigée par domaine. –
Dans mon cas, j'aimerais définir un index TTL basé sur l'environnement grails. Quel est le meilleur modèle pour cela? – Kirby
Yay, ça marche. J'ai essayé la méthode getBean, mais je lui ai passé 'FooBar' :) – rukoche
Ce qui précède ne fonctionnait pas pour moi jusqu'à ce que j'ai remplacé '.getMainContext.' par' .getMainContext(). ' – sebnukem
Merci, je l'ai corrigé après avoir vu que votre edit a été incorrectement rejeté –