2009-10-27 8 views
2

un problème peut-être simple, mais bizarre pourquoi je ne sais pas comment le faire:Unité dans les méthodes statiques

Unity (PRISM) et les méthodes statiques. Dans ce cas particulier, une méthode d'extension. Mais en général, comment puis-je accéder à une "instance fournie par unité" dans une méthode statique. Pensez par exemple d'un service de journalisation je veux accéder à la journalisation de certaines choses que je fais dans une méthode statique. Dois-je vraiment passer l'arbitre au service de journalisation lorsque je l'utilise?

Exemple (proche problème réel)

public static void HookupPrismEvent(ref UIElement, ILogger log) {...} 

semble étrange, je pense que je manque somethings, comme Container.Resolve (de résolution statique). N'ont rien trouvé, mais le conteneur, l'unité ou le statique ne sont pas les meilleurs termes de recherche du monde. Peut-être que je devrais juste essayer, mais encore, il se sent un peu "étrange" ..

Donc, des commentaires sur comment et si utiliser DI dans les méthodes statiques?

Chris

EDIT - ok, approche actuelle après la réponse: EDIT2, après y avoir réfléchi, récipient enlevé, fournissant "ce besoin" ....

public static void AttachPrismEvents(this UIElement element, IEventAggregator eA) 
    { 
     var ev = eA.GetEvent<KeyPressedEvent>(); 
     element.KeyDown += ((sender, e) => ev.Publish(e)); 
    } 

ou, avec l'exploitation forestière:

public static void AttachPrismEvents(this UIElement element, ILogger log, IEventAggregator eA) 
    { 
     log.Debug("Doing stuff"); 
     var ev = eA.GetEvent<KeyPressedEvent>(); 
     element.KeyDown += ((sender, e) => ev.Publish(e)); 
    } 

Répondre

1

Les types statiques et les membres sont généralement l'ennemi de toutes les choses DI. Techniquement, vous pourriez avoir une méthode Resolve statique, mais ce ne serait pas DI, mais plutôt un modèle connu sous le nom de Service Locator. Cependant, beaucoup de gens (moi y compris) considèrent que le service de localisation d'un anti-modèle pour plusieurs raisons:

  • Il fait des hypothèses implicites sur les exigences d'utilisation d'une API (l'appelant ne se fait pas au courant que doit être correctement un localisateur de service configuré avant que le membre peut être invoquée)
  • Il devient impossible de conteneurs nid
  • Il introduit une dépendance redondante sur le service de localisation se

Si vous devez avoir une méthode statique, vous devez passer la dépendance par l'intermédiaire Méthode I njection, mais je pense qu'il est souvent plus bénéfique de reconsidérer la conception globale de l'API. Souvent, la fonctionnalité souhaitée peut être modélisée en tant que membre sur l'un des paramètres d'entrée à la place.

+0

Ok, je pense que je vais essayer de fournir le conteneur. Je modifie le post, peut-être jeter un oeil et dites-moi ce que vous en pensez. Merci, Chris ... –

+0

J'ai mieux aimé votre proposition originale (c'est-à-dire en injectant l'ILogger). Cela délimite plus clairement la responsabilité de la méthode et prévient la «pollution responsable», et maintient également la méthode DI Container agnostique. –

+0

Oui, mais dans ce cas, je devrais injecter IEventAggregator et ILogger. Peut-être plus si nécessaire. Peut-être que je fournis ma propre façade pour le conteneur comme IContainer ou similaire. Avoir à vérifier, PRISM devrait soutenir la commutation du conteneur de toute façon, laisse voir comment ils le font ... –

Questions connexes