如何管理 ASP.NET 中的应用程序配置？

发布于 2024-08-26 09:28:10 字数 671 浏览 6 评论 0原文

我在管理 ASP.Net 应用程序的配置以部署到不同的客户端时遇到困难。需要摆弄的各种设置数量庞大，占用大量时间，而当前的配置方法过于复杂，无法让我们将这一责任推给支持合作伙伴。

对于处理此问题的更好方法或用于研究的良好信息来源有什么建议吗？

我们目前的做法：

Web.Config 中引用的各种 xml 配置文件，例如 AppSettings.xml。
特定站点的配置保存在重复的配置文件中。
包含特定于站点的数据列表的文本文件
在某些情况下，需要手动一次性更改
Windsor IOC 的数据库 C# 配置。

我们遇到的具体问题：

启用不同功能的不同站点、我们必须与之交谈的不同外部服务以及不同的业务规则。
不同的部署类型（实时、测试、训练）
配置密钥在不同版本之间发生变化（添加、删除），这意味着我们必须更新所有重复文件
我们仍然需要能够在应用程序运行时更改密钥

我们目前对如何更改密钥的想法我们可能会这样做：

将配置移动到动态编译的代码中（可能是 Boo、Binsor 或 JavaScript）
采用某种形式的差异/合并配置：将默认配置与实时/测试/训练配置和特定于站点的配置相结合

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

离线来电— 2024-09-02 09:28:10

无论您采取哪种方式，我认为为您的配置提供单一“事实来源”的概念可能很有价值。

如果您需要以某些组件自己的专门形式为它们提供配置，那么重复是可以的。

但为了保持你的理智，我认为你应该尝试并致力于在一个地方设置与你的应用程序相关的所有配置，然后使用一个定义良好的机制将其转换为 Web.config 中的条目，以及你可以使用的任何其他配置机制。必须支持。

根据您的支持合作伙伴的技能水平（无论他们是否会破坏 XML），我想您可能还想提供一个 GUI 实用程序，让他们转动这个“真实来源”配置文件中的所有旋钮，其中“应用”并运行转换/更新代码以对 Web.config 和 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 转换可能是您的最佳选择，因为您希望能够添加/更新/删除项目。

回复收藏 0 原文

真心难拥有 2024-09-02 09:28:10

如果使用所述配置项的代码是您管理/可以更改的代码（并且全部在托管代码空间/C# 中运行），我会考虑将获取设置的方法调用移植到至少具有 GetString 的单例类中() 方法就可以了。

GetObject() 非常有用（查看 .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)
    {
        ...
    }
}

If the code using said configuration items is code you manage/can change (and all running in managed code space/C#) I would look to porting the method calls that get settings to a call into a singleton-like class with at least a GetString() method on it.

GetObject() can be very useful (check out the .Net XML serialisation stuff - the Americans spell it with a 'z': serialization) ... useful for lots of stuff but also because it means you can start packaging related configuration items into single entries in the store.

As regards using a single store (a database table with cached access) or use your new configuration facade only to encapsulate where the configuration items are stored - that's up to you ... I strongly prefer a single store per product deployment for configuration because then you always know exactly where to look and where to make changes. All the web service references (WCF or otherwise) can be constucted and called using runtime-supplied strings ... :)

In terms of caching values for keys - I use my own in memory cache (for smaller apps) because the overhead on the stack is manageable ... things like memcache might work here (config store is accessed over TCP/on the network somewhere) ...

EDIT
Something like:

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 原文