Alternatives aux fichiers web.config dans ASP.NET

Question

Selon mon expérience, les fichiers web.config sont largement vilipendés. En particulier, je les ai trouvés difficiles à gérer lorsque vous avez plusieurs environnements à prendre en charge, et fiddly mettre à jour en raison du manque de validation à la mise à jour et la verbosité de XML.

Quelles sont les alternatives?

Answer 1

Depuis combien de temps ASP.NET existe-t-il? combien de sites Web de production l'utilisent?

Ils utilisent presque tous le web.config, tel qu'il est, prêt à l'emploi. Ils ne peuvent pas être "insultes" trop. Cela dit, regardez les nouvelles fonctionnalités d'ASP.NET dans .NET 4.0, y compris les fichiers web.config spécifiques à la configuration, et les transformations basées sur xml de web.config qui permettent d'utiliser des versions web.config spécifiques à l'environnement généré au moment du déploiement.

Vous pouvez insulter un peu moins.

Answer 2

Je ne suis pas du tout d'accord avec votre affirmation que les fichiers web.config sont "largement vilipendés". Dans mon expérience, ils sont faciles à maintenir et à gérer, et dans certains cas, sont le seul endroit où vous pouvez mettre des données de configuration.

Il est à noter que VS2010 prend en charge les transformations web.config de configuration par construction. J'ai un web.config, web.debug.config, et web.release.config. Les fichiers de débogage et de publication remplacent les chaînes de connexion spécifiées dans web.config et les remplacent par les chaînes correctes, en particulier pour mes serveurs SQL de débogage et de production. J'utilise aussi ceci pour rendre certaines valeurs de AppSettings spécifiques à la config. Comme vous pouvez ajouter une config build pour autant de cibles ou de configurations que vous le souhaitez, je ne vois pas pourquoi vous ressentirez le besoin de réinventer la roue en concevant un autre référentiel.

Cela dit, vous pouvez utiliser n'importe quel référentiel pour les données que vous voulez stocker. Une base de données, un fichier de configuration de texte du format de votre choix, une image cryptée, ou quoi d'autre.

Answer 3

Personnellement, cela ne me dérange pas Web.Config pour les petites applications ponctuelles, mais pour quelque chose de substantiel j'évite de les utiliser pour la configuration de l'application.

est ici ce que je fais ...

• I définissent une ou plusieurs interfaces pour ma configuration en fonction de la complexité.
• Je crée différentes implémentations par environnement (dev, stage, prod, etc.)
• J'utilise une classe de base abstraite pour définir une configuration commune. Puis, j'utilise Ninject pour l'injection de dépendances, donc l'implémentation appropriée est fournie en fonction de l'environnement que je cible.
• Je code toujours aux interfaces de configuration et profite des vérifications de temps de compilation.

Voici un exemple ...

// Config Contract 
public interface IWebAppConfig 
{ 
    string SmtpHost { get; } 
    string RootUrl { get; } 
} 

// Define Common Config Values (values that don't change per environment) 
public abstract class AbstractWebAppConfig : IWebAppConfig 
{ 
    public string SmtpHost { get { return "smtp.google.com"; } } 
    public abstract RootUrl { get; } 
} 

// Dev Config Settings 
public class DevWebAppConfig : AbstractWebAppConfig 
{ 
    public override string RootUrl { get { return "http://localhost:1322"; } } 
} 

// Stage Config Settings 
public class StageWebAppConfig : AbstractWebAppConfig 
{ 
    public override string RootUrl { get { return "http://stage.mysite.com"; } } 
} 

// Prod Config Settings 
public class ProdWebAppConfig : AbstractWebAppConfig 
{ 
    public override string RootUrl { get { return "http://www.mysite.com"; } } 
} 

Les avantages de cette approche:

• type Safe
• configuration est représentée comme objets non paires de valeurs clés (utiles pour le passage des regroupements logiques de valeurs de configuration au lieu de plusieurs valeurs)
• Plus facile à utiliser Classes de test dépendant des valeurs de configuration
• Partage con La figuration sur plusieurs applications est triviale
• Le déploiement de l'assembly contenant les implémentations de configuration déclenchera un recyclage du pool d'applications, un peu comme le redéploiement d'un fichier web.config.

Vous pouvez toujours utiliser le web.config pour définir l'environnement, ce qui est ce que je fais habituellement en ajoutant ce qui suit au appsettings:

<appSettings> 
    <!-- accepts: dev|stage|prod --> 
    <add key="Env" value="dev" /> 
</appSettings> 

Sinon, il pourrait être la machine à base en utilisant Envrionnement Variables ou une autre construction