2009-04-01 7 views
0

J'ai récemment dû mettre à jour une bibliothèque de contrôle relativement importante qui utilise Ninject 1.0 vers Ninject 2.0 pour aider à résoudre certains problèmes que j'avais avec 1.0. La mise à jour s'est bien passée et je pense que Ninject 2.0 est beaucoup plus rapide. Cependant, pour essayer d'éviter ce problème à l'avenir, j'ai créé ma propre interface d'injection de champs et de propriétés (qui appellera essentiellement des méthodes sur le conteneur IOC que je souhaite utiliser dans l'application Web actuelle). Maintenant, ma bibliothèque de contrôle est indépendante de tout conteneur IOC particulier qui va accélérer les changements dans ce domaine dans le futur.Inversion de contrôle pour votre conteneur Inversion de contrôle?

Je me demandais si quelqu'un d'autre avait fait la même chose?

Je suis content de ce qu'il a réalisé mais idéalement j'aimerais le mettre à jour. Dans mes contrôles, je crée souvent ces champs injectés comme protégés et les place dans le constructeur pour ce contrôle.

IBlogService _blogService = null; 
IEmailService _emailService = null; 

public Templates_BlogTemplate() 
{ 
    Inject(ref _blogService); 
    Inject(ref _emailService); 
} 

Le problème que j'ai avec ce qui précède est que je dois utiliser « ref » sur tous les objets pour définir réellement la propriété et je ne peux pas l'utiliser sur les propriétés directement.

Je préférerais faire quelque chose dans ce sens mais je ne pense pas que ce soit possible.

IBlogService _blogService = null; 
IEmailService _emailService = null; 

public Templates_BlogTemplate() 
{ 
    Inject(_blogService, _emailService); 
} 

Quelqu'un at-il des idées sur la façon de neaten le haut de code ou faire fonctionner d'une manière plus propre? Je voudrais également éviter les attributs de sorte qu'il oblige le développeur à prendre la décision d'injecter la variable à un certain point dans le contrôle.

Toutes les pensées et les sentiments sont les bienvenus.

Merci

+0

Je pense que ne pas avoir accès à la construction de contrôles utilisateur (ne pas être en mesure de changer la façon dont le constructeur est appelé) est l'une des choses agaçantes sur les contrôles utilisateur ASP.NET. Désolé, je n'ai pas de réponse utile. –

Répondre

1

d'injection de biens de soutien, et injectent des dépendances à "ce".

Dans mon cas, j'ai une classe de base qui appelle StructureMap.BuildUp (ce), et le contrôle utilisateur aurait des propriétés telles que:

public IBlogService _blogService{get;set;} 
public IEmailService _emailService{get;set;} 

La seule ligne spécifique à StructureMap je trouve dans la base classe. Si ninject vous permet de le faire, vous pouvez appeler votre code en lui donnant l'instance de contrôle, et lui permettre d'injecter les propriétés en fonction de sa configuration.

1

Vous voudrez peut-être regarder IServiceLocator comme décrit par Glenn Block

Il est une interface partagée qui peut être utilisé pour tirer profit de IoC sans prendre une dépendance pour le récipient.

Questions connexes