在創建特定於應用程序的設置時，有沒有過傳統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