在创建特定于应用程序的设置时，是否应该首选传统的ASP.NET appSettings而不是Sitecore设置(即<configuration><sitecore><settings><setting>(？我可以想到使用Sitecore设置的几个好处，例如，可以将这些设置拉到App_settings/Include文件夹中，但我不确定使用ASP.NET appSettings有什么好处。
我建议使用第三种方法。我强烈建议创建一个特定于您的项目(或程序集(的配置文件和相应的IConfigurationSectionHandler。这可以防止appSettings或sitecore/settings成为垃圾场，并防止魔术串(即配置密钥(在代码中乱丢。这种方法还允许开发人员快速确定特定程序集中代码的设置位置(配置文件的名称应与程序集类似(。此外，使用Slow Cheetah，您可以将配置转换添加到文件中。
我不喜欢将appSettings用于除特定于web应用程序项目本身的设置之外的任何其他设置。例如Trayek提到的aspnet:MaxHttpCollectionKeys、ClientValidationEnabled或UnobtrusiveJavaScriptEnabled
同样，除了存储Sitecore模块的设置或Sitecore系统的其他自定义之外，我不喜欢将Sitecore设置用于任何其他用途。
我认为Sitecore配置路由的优势正如您所描述的那样。也就是说，您的设置可以在App_settings/Include中分离到自己的.config文件中。通过configSource属性可以在本机上将设置移动到web.config之外，但Sitecore允许根据需要提供任意多的文件。这样，每个组件的设置都可以包含在它们自己的文件中(并以此方式分发(。
另一个优点是能够利用Sitecore的配置修补机制。如果组件安装了默认设置文件，但某个环境需要覆盖某个值，则可以放置第二个文件来覆盖这些值。
我们的配置也使用Sitecore设置。另一个优点是你有一个很好的界面来读取属性：
Sitecore.Configuration.Settings.GetBoolSetting("MySettings", false);
我能想到的唯一缺点是，Inlude文件夹中的文件将在运行时呈现，而web.config中的设置则不会。因此，如果您有数千个设置，您可以考虑将它们添加到web.config中。
在我们的项目中，我们倾向于在appSettings.config中设置全局设置，例如用于获取地址信息的URL，并在Sitecore设置中设置Sitecore特定的设置。
我认为这主要是一个偏好问题，尽管我认为可能有一些设置只能添加到<appsettings>中，比如aspnet:MaxHttpCollectionKeys(不过我还没有测试过将其添加到Sitecore设置中(。
Kevin的缺点是(至少在我看来(，你不能很快看到你在使用什么设置-你可以访问websitecore/admin/showconfig.aspx(尽管这只会给你web.config的<sitecore>...</sitecore>部分。
appSettings的优点是它可以在任何地方开箱即用，而且非常简单。了解ASP.NET的人都知道什么是appSettings。虽然Sean Kearney提供了一些很好的建议，但我觉得这有点违反了K.I.s.s.的规定。您已经有两个不同的配置设置选项。。。为什么要加三分之一？这似乎完全没有必要，除非你要处理数百个设置。
通过将appSettings放在自己的文件中，您可以快速轻松地使其更易于管理。