我在管理ASP.Net应用程序的配置时遇到了困难,无法为不同的客户端部署。大量不同的设置需要花费大量的时间,目前的配置方法太复杂,无法让我们将这个责任推到支持合作伙伴。
有哪些建议可以更好地处理这种或良好的信息来源进行研究?
目前我们如何做事:
我们遇到的具体问题:
我们目前关于如何处理这个问题的想法是:
答案 0 :(得分:2)
无论您采用哪种方式,我认为为您的配置提供单一“真实来源”的概念可能很有价值。
如果您需要以自己专门的形式为某些组件提供配置,则复制很好。
但是为了保持你的理智,我认为你应该尝试并设法在一个地方设置与你的应用程序相关的所有配置,然后是一个明确定义的机制,用于将其转换为Web.config中的条目,以及任何其他你必须支持的配置机制。
根据您的支持合作伙伴的技能水平(无论它们是否会破坏XML),我想您可能还想提供一个GUI实用程序,让它们旋转这个“真实来源”配置文件中的所有旋钮,使用“Apply”运行转换/更新代码,对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转换可能是你的方式,因为你希望能够添加/更新/删除项目。
答案 1 :(得分:0)
如果使用所述配置项的代码是您管理/可以更改的代码(以及所有在托管代码空间/ C#中运行的代码),我会将调用设置的方法调用移植到类似单一类的类中。至少有一个GetString()方法。
GetObject()可能非常有用(查看.Net XML序列化的东西 - 美国人用'z'拼写它:序列化)...对很多东西有用但也因为它意味着你可以开始打包相关配置项到商店中的单个条目。
关于使用单个商店(具有缓存访问权限的数据库表)或仅使用新的配置外观封装配置项的存储位置 - 这取决于您...我非常喜欢每个产品部署的单个商店配置,因为那样你总能确切知道在哪里查看以及在哪里进行更改。所有Web服务引用(WCF或其他)都可以使用运行时提供的字符串来构造和调用...:)
在缓存密钥值方面 - 我使用自己的内存缓存(对于较小的应用程序),因为堆栈上的开销是可管理的...像memcache这样的东西可能在这里工作(配置存储通过TCP /上访问网络某处)...
EDIT 类似的东西:
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)
{
...
}
}
答案 2 :(得分:0)
您可以考虑使用NAnt脚本进行自动化,并结合一些自定义.net实用程序来操作配置密钥。