2010-11-02 19 views
3

J'ai un service WCF .Net 4.0 que j'essaye d'installer le ninject pour. J'ai téléchargé le WCF extension pour ninject et ai jeté un coup d'oeil à travers l'exemple de TimeService. Tout semble assez simple, mais je ne vois pas comment ninject fait son travail correctement car il y a un constructeur sans paramètre qui injecte manuellement la dépendance. Dans la mesure où je comprends que ce code n'utilisera jamais la liaison de ninjas. Le premier constructeur appellera le second constructeur si je ne fournis pas de params. Quand j'effectue un test et que je passe dans mon objet de simulation, le second constructeur sera appelé. Je suis assez nouveau à la fois WCF et ninject donc excuses si je manque quelque chose d'évident!Comment fonctionne l'exemple de TimeService pour les extensions WCF de Ninject?

Quelqu'un peut-il expliquer?

Merci

Répondre

2

Par défaut, Ninject choisira le constructeur qui a le plus grand nombre de paramètres, qu'il a suffisamment d'informations pour remplir la liaison. Donc, si le module Ninject est capable de fournir une implémentation ISystemClock, Ninject préférera le second constructeur.

Le motif que vous montrez ici est souvent utilisé lorsque vous souhaitez autoriser les dépendances injectées, mais que vous avez toujours un défaut logique à appliquer en l'absence d'une dépendance spécifique. Comme vous l'avez souligné, vous pouvez fournir votre propre maquette ISystemClock lors des tests unitaires, ce qui vous donne l'avantage de tester de manière déterministe. De même, si vous avez des raisons de vouloir fournir une implémentation ISystemClock personnalisée, vous pouvez configurer vos modules Ninject avec une liaison correspondante. D'autre part, dans la plupart des cas, l'implémentation stock SystemClock est probablement la meilleure à utiliser. Ainsi, plutôt que de vous obliger à configurer une liaison ISystemClock pour que la classe fonctionne, un autre constructeur est fourni. utilise SystemClock comme implémentation par défaut. Ninject se rabattra sur ce constructeur si vous n'avez pas spécifié de liaison pour le service ISystemClock.

Modifier

Dans ce cas particulier, la raison pour laquelle il n'est pas en cours d'exécution est due à l'attribut suivant sur la classe TimeService:

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)] 

Je ne comprends pas tout à fait ce que tout va ici, mais cela empêche Ninject d'être utilisé pour créer le service. Si vous commentez cette ligne, cela devrait fonctionner comme prévu.

+0

Merci pour l'explication, c'est logique. Cependant, la liaison ninject n'appelle pas le second constructeur et j'ai testé cela en utilisant une autre classe qui a implémenté ISystemClock. Avez-vous utilisé cet échantillon? ça a marché? – littlechris

+0

@littlechris: Je viens de le télécharger et de trouver le problème. Voir ma réponse éditée. – StriplingWarrior

+0

Merci @StriplingWarrior! :) – littlechris