Конфигурация на основе сценариев в .net? - PullRequest
2 голосов
/ 06 января 2011

Одним из недостатков web.config / app.config является то, что это везде просто Magic Strings, так как это всего лишь файл XML.

Интерпретируемые языки, такие как PHP или Ruby, имеют то преимущество, что конфигурация - это просто исполняемый код. В .net выполнение чего-либо в коде требует перераспределения, что противоречит цели.

Теперь, прежде чем я создам свою собственную замену web.config на основе Boo или PowerShell, я хотел узнать, существует ли уже существующий?

В качестве примера, это здесь тривиально в коде, но очень сложно / неудобно в web.config:

IList<TimeZoneInfo> allowedTimeZones =
         System.TimeZoneInfo.GetSystemTimeZones()
           .Where(tz => tz.DisplayName.Contains("Central"));

По сути, каждый раз, когда вам нужно выполнить сложные действия для создания объекта, конфигурации на основе XML / String становятся очень грязными.

Например, если на самом деле допускается, что allowTimeZones должны начинаться с «Central», но не содержать «Europe», то вы начинаете строить свой собственный DSL по существу поверх XML (Правила <add action="startswith" value="Central"/> <add action="doesnotcontain" value="Europe/>). В коде мне нужно пройти через все эти циклы и либо иметь большой оператор switch, который переводит каждую строку в код, либо я мог бы использовать имена методов LINQ в качестве имен и использовать Reflection для их вызова.

Если в конфигурационном файле находится исполняемый код, я бы просто изменил его на

IList<TimeZoneInfo> allowedTimeZones =
         System.TimeZoneInfo.GetSystemTimeZones()
           .Where(tz => tz.DisplayName.StartsWith("Central") &&
                  !tz.DisplayName.Contains("Europe"));

Конечно, поскольку C # не является языком сценариев, этот пример будет представлен на языке, подобном Boo или PowerShell, который может быть просто выполнен приложением.

Ответы [ 2 ]

1 голос
/ 23 февраля 2011

Закончил строить свой собственный. По сути, используйте папку App_Code (которая автоматически перезапускает пул приложений и, таким образом, перезапускает приложение) и используйте немного Reflection в событии Application_Start, чтобы получить классы, реализующие определенный интерфейс / базовый класс, и запустить их.

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

0 голосов
/ 06 января 2011

Я не видел ничего подобного. Как вы сказали, вы можете разместить язык сценариев, а затем просто прочитать сценарий запуска.

Конечно, с помощью IOC вы можете развернуть измененные библиотеки DLL и указать на них файл web.config, который будет похожим, но с небольшой компиляцией (новой библиотеки конфигурации), чтобы проверить код вместо сценария времени выполнения, имеющего ошибки во время выполнения. Но со всей работой контейнера IOC у вас больше вероятность ошибок времени выполнения по сравнению со статическими ошибками.

Я полагаю, что большинство людей в настоящее время подвергают свой динамический риск этим двум сегментам: магические конфигурационные файлы, которые могут иметь незначительные ошибки, или магический МОК, который может содержать незначительные ошибки. Ваши предложения будут сценариями, которые вы не узнаете, если они потерпят неудачу, пока они не будут проанализированы - немного другое место для устранения неполадок - хотя я вижу преимущества.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...