2013-03-05 1 views
1

Есть ли когда-либо случай, когда традиционные настройки ASP.NET-приложений должны быть предпочтительнее настройки Sitecore (т. Е. <configuration><sitecore><settings><setting>) при создании настроек приложения? Я могу придумать пару преимуществ использования настроек Sitecore, например, возможность вытащить эти настройки в папку App_Settings/Include, но я не уверен в каких-либо преимуществах использования приложений ASP.NET appSettings.Параметры Sitecore всегда предпочтительны для параметров приложения ASP.NET в Web.config?

ответ

8

Я бы предложил третий подход. Я настоятельно рекомендую создать файл конфигурации и соответствующий IConfigurationSectionHandler, соответствующий вашему проекту (или сборке). Это предотвращает превращение appSettings или sitecore/settings в свалку и предотвращает засоривание магических строк (то есть ключа конфигурации) в вашем коде. Этот подход также позволяет разработчикам быстро определить, где настройки для кода в конкретной сборке (файл конфигурации должен быть назван похожим на сборку). Кроме того, используя Slow Cheetah, вы можете добавить конфигурационные преобразования в файл.

Мне не нравится использование appSettings для чего угодно, кроме настроек, которые очень специфичны для самого проекта веб-приложения. Примерами могут служить aspnet:MaxHttpCollectionKeys как упомянуто Trayek, ClientValidationEnabled или UnobtrusiveJavaScriptEnabled

В том же духе, мне не нравится использование настроек Sitecore ни для чего, кроме хранения настроек для модулей Sitecore или других настроек в системе Sitecore.

+0

Я изучал это и обнаружил, что IConfigurationSectionHandler [устарел с .NET 2.0] (http://msdn.microsoft.com/en-us/library/system.configuration.iconfigurationsectionhandler.aspx), и теперь они рекомендуют извлекать из ConfigurationSection , –

1

Мы также используем настройки Sitecore для наших конфигураций. Еще одно преимущество заключается в том, что у вас есть хороший интерфейс для чтения свойства:

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

Единственный недостаток, я могу думать о том, что файлы в Inlude-папке будет оказана во время выполнения и настроек в сети. config нет. Поэтому, если у вас есть тысячи настроек, вы можете добавить их в web.config.

+0

Конфигурация Sitecore построена при запуске приложения, поэтому нет никакого вреда для их использования при описании. Редактирование файла в app_config/include или web.config приведет к перезапуску AppPool. – ddysart

1

В наших проектах мы обычно используем глобальные настройки, такие как URL-адрес, используемый для получения адресной информации, в настройках appSettings.config и Sitecore в настройках Sitecore.

Я думаю, что это главным образом вопрос предпочтения, хотя я думаю, что могут быть настройки, которые могут быть добавлены только в <appsettings>, например aspnet:MaxHttpCollectionKeys (я еще не тестировал добавление его в настройки Sitecore).

Идти на недостаток Кевина (по крайней мере, как я понимаю), заключается в том, что вы не можете быстро увидеть, какие настройки вы используете, - вы можете перейти на сайт/sitecore/admin/showconfig.aspx для этого (хотя что только дает вам раздел.config.

2

Я думаю, что преимущество для маршрута конфигурации Sitecore, как вы описали. А именно, ваши настройки могут быть разделены на их собственный .config-файл в App_Settings/Include. настройки за пределами web.config несколько возможны из-за атрибута configSource, но Sitecore позволяет использовать столько файлов, сколько вам нужно. Таким образом, настройки каждого компонента могут содержаться в их собственном файле (и распространяться как таковые).

Другим преимуществом является возможность использования механизма исправления конфигурации Sitecore. Если ваш компонент устанавливает файл настроек по умолчанию, но определенная среда должна переопределить значение, вы можете поместить второй файл для переопределения значений.

1

Преимущество appSettings заключается в том, что он будет выходить из коробки в любом месте, и он мертв просто. Все, кто знает ASP.NET, знают, что такое appSettings.Хотя Шон Кирни предлагает хорошие советы, я чувствую, что это немного нарушает работу К.И.С.С. править. У вас уже есть два варианта настройки конфигурации ... зачем добавлять третий? Это кажется совершенно ненужным, если вы не имеете дело со сотнями настроек.

Вы можете быстро и легко сделать appSettings более управляемым, поместив его в свой собственный файл.

Смежные вопросы