默认值:硬编码,还是 .config 文件?

发布于 2024-12-08 20:02:04 字数 531 浏览 0 评论 0原文

我正在开发一个问题处理应用程序,网站用户输入问题,这些问题通过 WCF 服务发送到管理控制台,支持代理开始处理问题。

当问题通过网络出现时,它们会按项目 ID 和类别 ID 进行分组。

来自特定网站的所有问题都应具有相同的默认项目和类别 ID。

问题

目前尚不清楚这些默认值应该是什么,因为项目和类别是由支持代理经理将来在管理控制台中输入的。 (这些都还没有部署,我和支持团队之间不太可能召开会议来敲定这些细节)

问题:

处理这些默认值的最佳方法是什么?到目前为止我考虑的是:

1)对它们进行硬编码。硬编码的问题是部署后很难更改这些值。

2) 将 em' 粘在 .config 文件中。 这很灵活,并且可以在部署后轻松更改内容,但我几乎不认为它很优雅(或者至少对我来说是这样的感觉) )

如果您有任何类似的经历,或者只是好的见解和建议,我很乐意听到!谢谢你,

I'm working on an issue-tacking application, where website users enter issues which are sent over a WCF service to an administration console, where support agents begin handling the issue.

As issues come over the wire, they are grouped by a projectID and a categoryID

All issues coming from a specific website, should have the same default Project and CategoryID's.

Problem:

It is unknown at this point, what those default values should be since projects and categories are entered by support agent managers sometime in the future within the admin console. (None of this is yet deployed, and a meeting between myself and the support team to hammer out these details is unlikely)

Question:

What is the best way to handle these default values? What I've considered so far:

1) Hard-code them. The problem with hard-coding, is that it will be difficult to change the values after deployment.

2) Stick em' in a .config file. This is flexible, and will allow things to be changed easily after deployment, but I hardly think it's elegant (or at least it just feels that way to me)

If you've had any similar experiences, or just good insight and advice, I'd love to hear it! Thank you,

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

扫码二维码加入Web技术交流群

发布评论

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

评论(6

白况 2024-12-15 20:02:04

您甚至可以考虑更进一步,将默认值存储在数据库中。这将提供配置的灵活性和这些默认值的集中管理。

就我个人而言,我经常采取的方法是在代码中进行配置,但能够通过在配置文件或数据库中提供新值来覆盖默认值。我为什么要走这么远?这样我就可以用最少的配置进行部署,然后在需要时提供覆盖。

You might even consider going one step further and storing your defaults in the database. This will provide flexibility of configuration and centralized management of those defaults.

Personally, the approach I might often take is to have my configuration in code, but have the ability to override the defaults by supplying new values in the configuration file or in the Db. Why do I go this far? Well this way I can deploy with minimal configuration and then provide overrides if and when required.

哥,最终变帅啦 2024-12-15 20:02:04

由于您无法知道在部署时这些值应该是什么,因此您应该将它们放在配置中。您可能会发现它不优雅,但是对于可能需要在不更改代码的情况下更改值的情况,这是唯一的选择。

除非您知道部署既快速又简单,并且任何代码更改都可以快速部署且不会出现错误。

Since there is no way that you know what these values should be at deployment time, you should have them in configuration. You may find it inelegant, but with values that may need to change without code changes, this is the only option.

Unless you know that deployment is fast and easy and that any code changes can be deployed quickly and without error.

东北女汉子 2024-12-15 20:02:04

您还可以将它们存储在存储问题跟踪数据的数据库中。

You could also store them in the database where the issue tracking data is stored.

筱武穆 2024-12-15 20:02:04

首先,对合理的默认值进行硬编码以保持弹性。没有人喜欢一个由于缺少不那么严格必要的文本文件而变得毫无用处的程序。

其次,配置文件并不是处理自定义配置的不优雅的方式。根据您要部署到的环境,提供 GUI 配置工具是另一种选择。即最终用户会动态更改配置吗?或者系统管理员是否会进行计划中的更改?

First, hard-code reasonable defaults to maintain resiliency. No one likes a program which is made useless by the absence of not so strictly necessary text file.

Second, a config file is not at all an inelegant way to handle custom configuration. Depending on the environment you're deploying to, providing a gui config tool is another option. i.e. are end users going to be changing configs on thy fly? Or are sys admins going to be making planned changes?

昔日梦未散 2024-12-15 20:02:04

将它们放入配置中可能是最好的选择。如果您正在寻找一种很好的方法来访问它们,您可以创建一个充当访问器的静态类或使用依赖注入之类的东西。

访问器类示例:

public static class DefaultSupportValues
{
    public static string ProjectID
    {
        get
        {
            return ConfigurationManager.AppSettings["DefaultProjectId"];
        }
    }
}

Putting them in the configuration is probably the best choice. If you're looking to have a nice way to access them you can create a static class that acts as an accessor or use something like dependency injection.

Example accessor class:

public static class DefaultSupportValues
{
    public static string ProjectID
    {
        get
        {
            return ConfigurationManager.AppSettings["DefaultProjectId"];
        }
    }
}
記憶穿過時間隧道 2024-12-15 20:02:04

我认为您没有列出的第三个选项是将它们保存在数据库中。您可以采用多种缓存策略来解决性能问题。这种方法的好处是,您可以将应用程序托管在一台或多台服务器上,而无需为它们更新配置更改。

根据我的经验,这是处理这些情况的最佳方法。

I think a third option which you have not listed is to have them in a Database. There are various caching strategies you can employ to address performance concerns. The benefit of this approach is that you could host your application on one or more servers and not have it be a pain to update config changes for them.

In my experience, this has been the best approach for these cases.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文