none
чтение данных из веб конфига (спорный вопросик в реализации) RRS feed

  • Вопрос

  • вот с другом спорили и не пришли к единому выводу как лучше читать данные из конфига:
    1) устанавливать данные сразу

     

    public static class Config
    {
    static Config()
    {
    SiteUrl = ConfigurationManager.AppSettings["siteUrlParameter"];
    }
     
    public static string SiteUrl { get; private set; }
    
    

     

    2) вытаскивать параметры через методы

    public static class Config
    {
    public static string SiteUrl
    {
    get { return GetAppSettingsParameter("siteUrlParameter"); }
    }
     
    private static string GetAppSettingsParameter(string parameterName)
    {
    return GetAppSettingsParameter(parameterName, false);
    }
     
    private static string GetAppSettingsParameter(string parameterName, bool canBeEmpty)
    {
    string result = string.Empty;
     
    if (!string.IsNullOrEmpty(ConfigurationManager.AppSettings[parameterName]))
    {
    result = ConfigurationManager.AppSettings[parameterName];
    }
    else if (!canBeEmpty)
    {
    throw new Exception(parameterName + " parameter is not defined in the default configuration file");
    }
     
    return result;
    }
    }


    я вот думаю что 2й вариант несколько теряет в производительности так как хоть и переменные статик но дергают метод и постоянно считывают данные из конфига.
    у кого какое мнение по этому поводу? а что мсдн предлагет использовать?

    6 апреля 2011 г. 7:16

Ответы

  • Вообще дело вкуса. С моей точки зрения есть 2 момента:

    Код должен быть читаемым (то бишь злоупотреблять витеаватой цепочкой вызовов не ст0ит)

    Хард-код - это зло. Если одни и теже данные из конфига фитаются много раз - лучше сделать свойства типа этого:

    public static string SiteUrl
    {
    get { return ConfigurationManager.AppSettings["siteUrlParameter"]; }
    }

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

    Don't forget to vote for useful replies and/or mark answers for your questions - that helps other guys to find the answer faster.
    • Предложено в качестве ответа Dmitry Pavlov 6 апреля 2011 г. 19:13
    • Помечено в качестве ответа Abolmasov DmitryModerator 8 апреля 2011 г. 10:56
    6 апреля 2011 г. 19:12
  • Третий вариант - написать полноценный ConfigurationSection, со строгой типизацией, значениями по умолчанию, возможностью вынести в отдельный файл и прочими плюшками.

    И, кстати, данные их конфига не читаются при каждом обращении к AppSettings. ConfigurationManager вычитывает сразу все AppSettings в память, скорее всего при первом обращении. Нет смысла делать еще один уровень кэширования.


    My blog | My pet project

    7 апреля 2011 г. 12:45

Все ответы

  • Продолжение тут на GotDotNet
    Don't forget to vote for useful replies and/or mark answers for your questions - that helps other guys to find the answer faster.
    6 апреля 2011 г. 19:09
  • Вообще дело вкуса. С моей точки зрения есть 2 момента:

    Код должен быть читаемым (то бишь злоупотреблять витеаватой цепочкой вызовов не ст0ит)

    Хард-код - это зло. Если одни и теже данные из конфига фитаются много раз - лучше сделать свойства типа этого:

    public static string SiteUrl
    {
    get { return ConfigurationManager.AppSettings["siteUrlParameter"]; }
    }

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

    Don't forget to vote for useful replies and/or mark answers for your questions - that helps other guys to find the answer faster.
    • Предложено в качестве ответа Dmitry Pavlov 6 апреля 2011 г. 19:13
    • Помечено в качестве ответа Abolmasov DmitryModerator 8 апреля 2011 г. 10:56
    6 апреля 2011 г. 19:12
  • Третий вариант - написать полноценный ConfigurationSection, со строгой типизацией, значениями по умолчанию, возможностью вынести в отдельный файл и прочими плюшками.

    И, кстати, данные их конфига не читаются при каждом обращении к AppSettings. ConfigurationManager вычитывает сразу все AppSettings в память, скорее всего при первом обращении. Нет смысла делать еще один уровень кэширования.


    My blog | My pet project

    7 апреля 2011 г. 12:45