2010-12-08 49 views
0

Dans une application MVC, nous avons besoin de créer une classe de paramètres de configuration nécessaire dans toute l'application. C'est une préoccupation transversale en ce sens qu'elle est nécessaire dans les contrôleurs, parfois dans la logique du domaine, ainsi que dans les extensions HtmlHelper. Le fait qu'il y ait tellement de places différentes est ce qui me fait trébucher.Classe de configuration ASP.NET MVC utilisant IoC

La classe remplira les paramètres extraits de web.config, ainsi qu'une table dans un DB. La requête des paramètres de la base de données sera mise en cache, donc je ne suis pas inquiet à ce sujet.

Dans les années passées, j'ai peut-être créé un type statique de classe ou de singleton, mais je ne veux pas perdre la testabilité que j'ai maintenant. Quel serait le meilleur moyen d'instancier cette classe et de pouvoir y accéder à peu près n'importe où dans l'application?

Répondre

0

Je pense que le projet CodePlex MvcContrib a fourni quelques crochets à utiliser au moins 3 fournisseurs du CIO pour autant que je ne windsor, structurmap, spring.net ... mais je ne l'ai pas utilisé moi-même vous pouvez en savoir plus ici http://mvccontrib.codeplex.com/

et peut-être vous pouvez regarder dans le code source de ce projet et voir où vous pouvez aller à partir de là ...

HTH

3

je continuerais à utiliser un singleton. Mais un singleton qui enveloppe une interface, ce qui le rend également testable.

public class Configuration 
{ 
    private IConfiguration _config; 

    public static IConfiguration Instance { get { return _config; }} 

    public static void Assign(IConfiguration config) 
    { 
     _config = config; 
    } 
} 

Utilisez simplement Assign dans global.asax ou l'un de vos tests unitaires.

Si vous voulez le faire correctement, vous devez fournir les paramètres de configuration directement dans les constructeurs de vos objets.

Au lieu de

public class MyService 
{ 
    public MyService() 
    { 
     var confString = Configuration.Instance.GetConnectionString() 
    } 
} 

Vous feriez:

public class MyService 
{ 
    public MyService(string confString) 
    {} 
} 

Enfin, je ne serais pas toutes les dépendances de configuration dans les aides HTML. En faisant ainsi vous ajoutez la logique d'affaires à vos vues qui casse separation of concerns

0

Je refactoriserais mon application pour ne pas utiliser la configuration partout. J'utilise la configuration dans les contrôleurs seulement. Mes vues n'ont aucune logique, mon modèle de domaine n'a qu'une logique métier, pas une logique d'application.