在创建特定于应用程序的设置时，有没有过传统ASP.NET应用程序设置应优于Sitecore设置（即<configuration><sitecore><settings><setting>）的情况？我可以考虑使用Sitecore设置的两个优点，例如，可以将这些设置放到App_Settings/Include文件夹中，但我不确定使用ASP.NET appSettings有什么优势。Sitecore设置始终优先于Web.config中的ASP.NET应用程序设置吗？
我会建议第三种方法。我强烈建议创建一个配置文件，并对应于您的项目（或程序集）的相应IConfigurationSectionHandler。这可以防止appSettings或sitecore/settings成为垃圾场，并防止在您的代码中散布魔法字符串（即配置密钥）。这种方法还允许开发人员快速识别特定程序集中代码的设置（配置文件应该与程序集类似）。此外，使用Slow Cheetah，您可以将配置转换添加到文件中。
我不喜欢使用appSettings以外的其他设置，这些设置对于Web应用程序项目本身来说非常具体。的例子是如aspnet:MaxHttpCollectionKeys提到Trayek，ClientValidationEnabled或UnobtrusiveJavaScriptEnabled
与此类似，我不喜欢比存储用于Sitecore的模块或其他定制的Sitecore的系统设置的任何其他使用Sitecore的设置。
我们还为我们的配置使用Sitecore设置。另一个好处是，你有一个很好的接口来读取性能：
Sitecore.Configuration.Settings.GetBoolSetting("MySettings", false);
唯一的缺点我能想到的是，在该Inlude文件夹中的文件将在运行时在网络设置中呈现。配置不是。所以如果你有成千上万的设置，你可以考虑将它们添加到web.config中。
Sitecore配置是在应用程序启动时构建的，因此不会像您所描述的那样使用它们。在app_config/include或web.config中编辑文件都会导致AppPool重新启动。 – ddysart 2013-03-05 15:11:31
在我们的项目中，我们倾向于在appSettings.config和Sitecore设置中的Sitecore特定设置中使用全局设置，例如用于获取地址信息的URL。
我认为这主要是偏好的问题，但我觉得可能是只能被添加到<appsettings>设置，如aspnet:MaxHttpCollectionKeys（我没有测试它添加到Sitecore的设置虽然）。
继续关注凯文的缺点（至少，我是怎么理解的），是你不能很快看到你使用的设置 - 你可以去网站/ sitecore/admin/showconfig.aspx（尽管只有给你的web.config的<sitecore>...</sitecore>部分
我认为Sitecore配置路由的好处就像你描述的一样，也就是说，你的设置可以在App_Settings/Include中分离到它们自己的.config文件中。 web.config以外的设置在本地可以通过configSource属性实现，但是Sitecore可以根据需要允许多个文件。这样，每个组件的设置都可以包含在它们自己的文件中（并且可以像这样分发）
另一个优势是能够利用Sitecore的配置修补机制。如果您的组件安装了默认设置文件，但某个环境需要覆盖某个值，则可以放置第二个文件来覆盖这些值。
appSettings的优势在于它可以随时随地使用，而且它非常简单。每个知道ASP.NET的人都知道appSettings是什么。虽然肖恩科尔尼提供了一些很好的建议，但我觉得这有点违反K.I.S.S.规则。您已经有两个不同的配置设置选项...为什么添加第三个选项？这似乎是不必要的，除非你正在处理数百个设置。
通过将appSettings放入自己的文件中，您可以快速轻松地使appSettings更易于管理。
我在研究这个，发现IConfigurationSectionHandler已经[自.NET 2.0开始弃用]（http://msdn.microsoft.com/en-us/library/system.configuration.iconfigurationsectionhandler.aspx），他们现在推荐从ConfigurationSection派生。 – 2013-03-12 16:52:16