1

<configuration><sitecore><settings><setting>在创建特定于应用程序的设置时，是否有过传统的 ASP.NET appSettings 应该优先于 Sitecore 设置（即）的情况？我可以想到使用 Sitecore 设置的几个优点，例如，能够将这些设置拉到 App_Settings/Include 文件夹中，但我不确定使用 ASP.NET appSettings 的任何优点。

4

5 回答 5

8

我建议第三种方法。我强烈建议创建一个配置文件，并与IConfigurationSectionHandler您的项目（或程序集）相对应。这可以防止appSettings或sitecore/settings成为垃圾场，并防止魔术字符串（即配置密钥）被乱扔在您的代码中。这种方法还允许开发人员快速确定特定程序集中代码的设置位置（配置文件的名称应与程序集相似）。此外，使用 Slow Cheetah，您可以将配置转换添加到文件中。

除了非常特定于 Web 应用程序项目本身的设置之外，我不喜欢将 appSettings 用于任何其他设置。例子aspnet:MaxHttpCollectionKeys就像 Trayek 提到的那样，ClientValidationEnabled或者UnobtrusiveJavaScriptEnabled

同样，我不喜欢将 Sitecore 设置用于存储 Sitecore 模块的设置或其他对 Sitecore 系统的自定义设置之外的任何事情。

于 2013-03-05T16:58:04.787 回答
2

我认为 Sitecore 配置路线的优势正如您所描述的那样。也就是说，您的设置可以在 App_Settings/Include 中分离到它们自己的 .config 文件中。通过 configSource 属性将设置移动到 web.config 之外在某种程度上是可能的，但 Sitecore 允许您需要任意数量的文件。这样，每个组件的设置都可以包含在它们自己的文件中（并以此方式分发）。

另一个优势是能够利用 Sitecore 的配置修补机制。如果您的组件安装了默认设置文件，但某个环境需要覆盖某个值，您可以放置​​第二个文件来覆盖这些值。

于 2013-03-05T15:27:46.200 回答
1

我们还使用 Sitecore 设置进行配置。另一个优点是您有一个很好的界面来读取属性：

Sitecore.Configuration.Settings.GetBoolSetting("MySettings", false);

我能想到的唯一缺点是，Inlude 文件夹中的文件将在运行时呈现，而 web.config 中的设置则不会。因此，如果您有数千个设置，您可以考虑将它们添加到 web.config。

于 2013-03-05T14:51:35.610 回答
1

在我们的项目中，我们倾向于在 appSettings.config 中使用全局设置，例如用于获取地址信息的 URL，在 Sitecore 设置中使用 Sitecore 特定设置。

我认为这主要是一个偏好问题，尽管我认为可能有一些设置只能添加到 中<appsettings>，例如aspnet:MaxHttpCollectionKeys（虽然我还没有测试将它添加到 Sitecore 设置中）。

继续凯文的缺点（至少，我如何理解），是您无法快速查看您正在使用的设置 - 您可以访问 website/sitecore/admin/showconfig.aspx （尽管这只会给您web.config的<sitecore>...</sitecore>部分。

于 2013-03-05T15:25:43.280 回答
1

appSettings 的优点是它可以在任何地方开箱即用，而且非常简单。了解 ASP.NET 的每个人都知道 appSettings 是什么。虽然 Sean Kearney 提供了一些很好的建议，但我觉得这有点违反 KISS 规则。您已经有两种不同的配置设置选项......为什么要添加第三个？这似乎完全没有必要，除非您要处理数百个设置。

您可以通过将 appSettings 放入自己的文件中来快速轻松地使 appSettings 更易于管理。

于 2013-03-05T22:18:25.713 回答