Есть ли когда-либо случай, когда традиционные настройки ASP.NET-приложений должны быть предпочтительнее настройки Sitecore (т. Е. <configuration><sitecore><settings><setting>
) при создании настроек приложения? Я могу придумать пару преимуществ использования настроек Sitecore, например, возможность вытащить эти настройки в папку App_Settings/Include, но я не уверен в каких-либо преимуществах использования приложений ASP.NET appSettings.Параметры Sitecore всегда предпочтительны для параметров приложения ASP.NET в Web.config?
ответ
Я бы предложил третий подход. Я настоятельно рекомендую создать файл конфигурации и соответствующий IConfigurationSectionHandler
, соответствующий вашему проекту (или сборке). Это предотвращает превращение appSettings
или sitecore/settings
в свалку и предотвращает засоривание магических строк (то есть ключа конфигурации) в вашем коде. Этот подход также позволяет разработчикам быстро определить, где настройки для кода в конкретной сборке (файл конфигурации должен быть назван похожим на сборку). Кроме того, используя Slow Cheetah, вы можете добавить конфигурационные преобразования в файл.
Мне не нравится использование appSettings для чего угодно, кроме настроек, которые очень специфичны для самого проекта веб-приложения. Примерами могут служить aspnet:MaxHttpCollectionKeys
как упомянуто Trayek, ClientValidationEnabled
или UnobtrusiveJavaScriptEnabled
В том же духе, мне не нравится использование настроек Sitecore ни для чего, кроме хранения настроек для модулей Sitecore или других настроек в системе Sitecore.
Мы также используем настройки Sitecore для наших конфигураций. Еще одно преимущество заключается в том, что у вас есть хороший интерфейс для чтения свойства:
Sitecore.Configuration.Settings.GetBoolSetting("MySettings", false);
Единственный недостаток, я могу думать о том, что файлы в Inlude-папке будет оказана во время выполнения и настроек в сети. config нет. Поэтому, если у вас есть тысячи настроек, вы можете добавить их в web.config.
Конфигурация Sitecore построена при запуске приложения, поэтому нет никакого вреда для их использования при описании. Редактирование файла в app_config/include или web.config приведет к перезапуску AppPool. – ddysart
В наших проектах мы обычно используем глобальные настройки, такие как URL-адрес, используемый для получения адресной информации, в настройках appSettings.config и Sitecore в настройках Sitecore.
Я думаю, что это главным образом вопрос предпочтения, хотя я думаю, что могут быть настройки, которые могут быть добавлены только в <appsettings>
, например aspnet:MaxHttpCollectionKeys (я еще не тестировал добавление его в настройки Sitecore).
Идти на недостаток Кевина (по крайней мере, как я понимаю), заключается в том, что вы не можете быстро увидеть, какие настройки вы используете, - вы можете перейти на сайт/sitecore/admin/showconfig.aspx для этого (хотя что только дает вам раздел.config.
Я думаю, что преимущество для маршрута конфигурации Sitecore, как вы описали. А именно, ваши настройки могут быть разделены на их собственный .config-файл в App_Settings/Include. настройки за пределами web.config несколько возможны из-за атрибута configSource, но Sitecore позволяет использовать столько файлов, сколько вам нужно. Таким образом, настройки каждого компонента могут содержаться в их собственном файле (и распространяться как таковые).
Другим преимуществом является возможность использования механизма исправления конфигурации Sitecore. Если ваш компонент устанавливает файл настроек по умолчанию, но определенная среда должна переопределить значение, вы можете поместить второй файл для переопределения значений.
Преимущество appSettings заключается в том, что он будет выходить из коробки в любом месте, и он мертв просто. Все, кто знает ASP.NET, знают, что такое appSettings.Хотя Шон Кирни предлагает хорошие советы, я чувствую, что это немного нарушает работу К.И.С.С. править. У вас уже есть два варианта настройки конфигурации ... зачем добавлять третий? Это кажется совершенно ненужным, если вы не имеете дело со сотнями настроек.
Вы можете быстро и легко сделать appSettings более управляемым, поместив его в свой собственный файл.
- 1. Параметры авторизации web.config ASP.NET игнорируются
- 2. Параметры приложения ASP.NET debug = «false» в перерыве web.config Javascript
- 3. 301 Перенаправление в ASP.NET web.config, включая параметры
- 4. Добавить параметры приложения в web.config с Octopus Deploy
- 5. тег «sc.include» в Sitecore web.config
- 6. Конфигурация задач Sitecore из web.config
- 7. Передача параметров MSBuild в Web.config Преобразование XDT
- 8. ASP.Net mvc Параметры Url.Action всегда равны нулю.
- 9. Обработка параметров приложения ASP.NET MVC
- 10. Параметры рендеринга Sitecore
- 11. Sitecore MVC Стандартные параметры рендеринга
- 12. Развертывание приложения ASP.NET MVC для IIS7 и сохранения чистого web.config
- 13. Asp.Net Web.Config Sharing
- 14. Какие варианты конфигурации предпочтительны в искровом режиме?
- 15. Доступные параметры для компиляции большого приложения ASP.NET
- 16. Почему предпочтительны директивы AngularJS?
- 17. проблема web.config в ASP.Net
- 18. Каков правильный способ поместить параметры в web.config в MVC - ASP.NET
- 19. Управление web.config в многосетевом решении sitecore
- 20. Пример входа в asp.net (Sitecore)
- 21. Переопределить настройки приложения в web.config
- 22. Параметры для создания настраиваемых диалогов в Sitecore
- 23. Передача параметров в Sitecore Sublayout
- 24. Web.Config приложения silverlight vs Web.Config приложения для размещения Silverlight
- 25. Что означают параметры TargetFramework в web.config в ASP.NET MVC?
- 26. Изменение вашего web.config из вашего приложения ASP.NET
- 27. UI Designer для редактирования Web.config в ASP.net
- 28. ASP.NET web.config appsettings persistence
- 29. Как передать параметры формам в Sitecore WFFM
- 30. Sitecore: GetMediaStream всегда null
Я изучал это и обнаружил, что IConfigurationSectionHandler [устарел с .NET 2.0] (http://msdn.microsoft.com/en-us/library/system.configuration.iconfigurationsectionhandler.aspx), и теперь они рекомендуют извлекать из ConfigurationSection , –