Плюсы / минусы чтения строки подключения из физического файла против объекта приложения (ASP.NET)? - PullRequest
Новая
       37

Плюсы / минусы чтения строки подключения из физического файла против объекта приложения (ASP.NET)?

1 голос
/ 09 апреля 2010

мое приложение ASP.NET считывает файл xml, чтобы определить, в какой среде оно находится в данный момент (например, локальное, разработка, производство).

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

Я вступаю в фазу развития, где эффективность становится проблемой. Я не думаю, что это хорошая идея - читать файл на физическом диске каждый раз, когда я хочу получить доступ к базе данных (очень часто).

Я думал о сохранении строки подключения в приложении ["ConnectionString"]. Таким образом, код будет 

public static string GetConnectionString
        {
            if (Application["ConnectionString"] == null)
            {
                XmlDocument doc = new XmlDocument();
                doc.Load(HttpContext.Current.Request.PhysicalApplicationPath + "bin/ServerEnvironment.xml");
                XmlElement xe = (XmlElement) xnl[0];

                switch (xe.InnerText.ToString().ToLower())
                {
                    case "local":
                        connString = Settings.Default.ConnectionStringLocal;
                        break;

                    case "development":
                        connString = Settings.Default.ConnectionStringDevelopment;
                        break;

                    case "production":
                        connString = Settings.Default.ConnectionStringProduction;
                        break;

                    default:
                        throw new Exception("no connection string defined");
                }
                Application["ConnectionString"] = connString; 
            }
            return Application["ConnectionString"].ToString();
        }

Я не проектировал приложение, поэтому я думаю, что должна быть причина для прочтения XML-файла каждый раз (для изменения настроек во время работы приложения?). У меня очень мало понятия о внутренней работе. Каковы плюсы и минусы? Как вы думаете, я бы увидел небольшой прирост производительности за счет реализации вышеуказанной функции?

СПАСИБО

Ответы [ 2 ]

7 голосов
/ 09 апреля 2010

Ничего себе. Брось это в мусорное ведро.

Все файлы .config (web или app.config) имеют раздел, посвященный строкам подключения, и их можно прочитать с помощью свойства ConfigurationManager.ConnectionStrings .

Для локальных и тестовых сред я просто настраиваю три строки подключения следующим образом 

<connectionStrings>
    <add name="default.local" connectionString="etc ..>
    <add name="default.test" connectionString="etc ..>
    <add name="default" connectionString="etc ..>
</connectionStrings>

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

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

РЕДАКТИРОВАТЬ: забыл упомянуть, что эти значения кэшируются в памяти, и приложение перезапускается, когда они изменяются (может быть проблемой, может быть полезно). Производительность абсолютно нормальная, если перейти непосредственно в файл .config через класс ConfigurationManager. *

3 голосов
/ 09 апреля 2010

Я полностью согласен с Джеймсом Вестгейтом. Если вы используете web.config, вам не нужно заботиться об этой проблеме.

Если по какой-либо причине вы не можете использовать web.config, я бы сказал, что ваш подход правильный. Сохраняя значение в хранилище приложений, вы избегаете многократного чтения строки соединений с диска.

Если вам нужно изменить строку подключения, вам придется перезапустить приложение. Строка подключения не должна меняться каждый день, поэтому это не должно быть проблемой.

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

...