2010-03-23 60 views
5

我很难管理ASP.Net应用程序的配置,以便为不同的客户端部署。需要浪费的不同设置的庞大体积会占用大量时间,而当前的配置方法太复杂,无法将此责任推给合作伙伴。如何管理ASP.NET中的应用程序配置?

任何关于更好的方法来处理这个或好的信息来源研究的建议?

我们如何在现在的事:

这些Web.Config中引用,例如AppSettings.xml
  • 各种XML配置文件。
  • 特定站点的配置保存在重复的配置文件中。包含特定的网站
  • 在某些情况下的数据,手动一次性更改名单温莎IOC数据库
  • C#配置
  • 文本文件。

我们遇到的具体问题:

  • 不同部位具有不同特征的启用,我们必须跟和不同的业务规则不同的外部服务。
  • 不同的部署类型(现场,测试,培训)
  • 配置密钥不同版本进行更改(得到补充,删除),这意味着我们必须更新所有的重复文件
  • 我们仍然需要能够改变键,在该应用程序是在我们如何处理这个运行

我们目前的想法是:

  • 移动配置成动态编译的代码(可能是嘘声,Binsor或JavaScript)
  • 有某种形式的版本比较/合并配置:用活/测试/培训配置和特定的站点配置结合了默认配置
+0

最后我去了一个合并配置系统。配置文件存储在树中。加载密钥时,它首先查找最具体的版本(站点和部署类型),然后查看更多通用文件,直到找到密钥。我从所有这些中学到的主要内容是,拥有您在源代码管理中进行管理的所有配置是非常有帮助的。 – GlennS 2011-01-07 14:00:44

回答

0

如果代码中使用该配置项是您管理代码/可改变(以及所有在托管代码空间/ C#中运行)我会考虑将调用设置的方法调用移植到类似单例的类中,并且至少有一个GetString()方法。 (可以看看.Net XML序列化的东西 - 美国人拼出一个'z':序列化)...对很多东西很有用,但也因为这意味着你可以开始打包将相关的配置项目转换为商店中的单个条目。

关于使用单个存储(具有缓存访问的数据库表)或仅使用新的配置门面来封装配置项的存储位置 - 这取决于您...我强烈希望每个产品部署使用一个存储进行配置,因为那样你总是知道在哪里看以及在哪里做出改变。所有的Web服务引用(WCF或其他)都可以使用运行时提供的字符串来构建和调用......:)

在缓存键的值方面 - 我使用我自己的内存缓存(对于较小的应用程序),因为栈上的开销是可管理的......类似于memcache的东西可能在这里工作(配置存储通过TCP访问/网络的地方)......

编辑 喜欢的东西上:

public class ConfigurationStore 
{ 
    private static ConfigurationStore _instance = null; 

    public static ConfigurationStore Instance { 
     get { 
     if(_instance == null) 
     { 
      _instance = new ConfigurationStore(); 
     } 

     return _instance; 
     } 
    } 

    public string GetValue(string key) 
    { 
     .... 
    } 

    public Object GetObject(string key) 
    { 
     ... 
    } 
} 
0

您可以考虑看着楠脚本自动化与一些自定义的.NET工具来操纵配置按键组合。

2

无论你走到哪里,我认为对于你的配置有一个单一的“真相源”的概念可能是有价值的。

复制是好的,如果你需要提供配置给他们自己的专门形式的一些组件。

但是为了保持您的理智,我认为您应该尝试并设法在一个位置设置与您的应用程序相关的所有配置,然后提供一个定义良好的机制,将其转换为Web.config中的条目,以及任何其他配置机制,你必须支持。

根据支持合作伙伴的技能水平(不管他们是否会破坏XML),我想你可能还想提供一个GUI实用程序,让他们在这个“真相源”配置中旋转所有旋钮文件,用“应用”去运行变换/更新代码,以对Web.config &朋友进行必要的更改。

然后,为了管理您针对不同站点/客户的配置,理论上您有一个配置文件需要管理。

注意:在ASP.NET 4.0中,将提供构建时配置转换机制(请参阅http://blog.hmobius.com/post/2010/02/17/ASPNET-40-Part-4-Config-Transformation-Files.aspx),这可能使此任务更容易。看起来你可以使用这个与非web项目的一些黑客(见http://philbolduc.blogspot.com/2010/03/using-config-transforms-outside-web.html)。但是,如果您需要在部署时进行这些更改,则可能会遇到编写自定义工具的问题,尽管看起来XDT转换可能是适合您的方式,因为您希望成为能够添加/更新/删除项目。

相关问题