Question

我正在开发一个代码库，它有很多相同的ConfigurationManager.AppSetting调用。

这听起来像是一个可能的性能问题吗？

或者因为数据非常小是微不足道而且不“昂贵”？不断返回文件获取数据，或.NET运行时缓存文件/值/调用？

如果这不是性能问题，它只是一种访问应用程序配置值的无组织方法，应该重新考虑更清晰，更一致地实现访问设置吗？

Answer 1

我想说的是代码可维护性问题比性能问题更多。 AppSettings上的简单字典查找不会成为问题，除非您的代码尝试在运行数百次的循环中对AppSettings执行查找。当然这样的代码会导致性能问题。但更重要的是，您将在整个代码库中拥有ConfigurationManager.AppSettings["MyKey"]。你正在引入一个神奇的字符串。如果必须更改配置文件中的密钥，则必须进行彻底搜索并替换所有项目。此外，我们通常根据appSettings中存储的值做出一些决定。它并不总是直接读取并按原样使用值。有时您会根据价值做出决定。例如，

if (ConfigurationManager.AppSettings["DebugMode"] == "yes")
  do this
else
  do that

你可能会在一百个地方重复这个逻辑。现在让我们说你需要在那里添加另一个条件：

if (ConfigurationManager.AppSettings["DebugMode"] == "yes" || ConfigurationManager.AppSettings["InternetNotAvailable"] == "yes")
  do this
else
  do that

这变得混乱。你的代码开始变臭了。

所以，我总是建议我的开发团队永远不要在代码中的任何地方使用ConfigurationManager.AppSettings。使用一些静态类来读取配置值，并将所有这些决策预先转换为单个变量。例如，

static class ConfigHelper
{
  private readonly static bool ExternalWebserviceCallAllowed = ConfiguationManager.AppSettings["DevMode"] == "false" && ConfigurationManager.AppSettings["InternetAvailable"] == "true";

}

.
.
if (ConfigHelper.ExternalWebserviceCallAllowed)
   do this
else
   do that

这不仅性能更好，而且代码具有高度可维护性和可扩展性。

Answer 2

这里有一些事情。

您可以使用ANTS Profiler或DotTrace之类的东西来验证这是否是性能问题，以便检查应用程序的性能
我想说如果你把呼叫分散到各地，你可能会在未来开放一些问题，例如，如果你决定更改其中一个应用设置的名称，那么可能是灾难性的。如果出于任何原因允许将来进行更改，我个人建议集中处理此类事情。
从性能的角度来看，要小心不要“预先优化”不需要的东西，否则在不需要时可能会增加更多的复杂性。

重复调用ConfigurationManager.AppSettings获取appsetting值的性能问题？

2 个答案: