Проблемы с Web.config и App.config

Хорошо, ребята, пока я ждал помощи, я принялся за работу и смог найти хорошее решение (на мой взгляд, конечно: P).

Позвольте мне поделиться с вами:

Итак, у меня есть одно веб-приложение, или одно консольное приложение, или какое-то другое приложение и множество библиотек классов, и мне нужно хранить информацию (разную для каждого проекта Visual Studio), которая будет меняться во время выполнения.

Хранение этой информации внутри Web.config или App.config не является хорошей идеей для решения многих возникающих проблем.

Другой вариант - иметь один файл конфигурации XML для каждого проекта.

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

IMO THIS IS THE FASTEST AND EASIEST WAY TO SOLVE THE PROBLEM, нет необходимости использовать сторонние фреймворки (как и время, необходимое для его изучения / программирования).

.

Пример кода:

    protected void Page_Load(object sender, EventArgs e)
    {
        DBConfiguration cachConf;
        cachConf = Cache["cachConf"] as DBConfiguration;
        if (cachConf == null)
        {
            cachConf = new DBConfiguration();

            XmlDocument doc = new XmlDocument();
            doc.Load(HttpContext.Current.Request.PhysicalApplicationPath + "bin/MyConf.xml");
            XmlNodeList xnl = doc.GetElementsByTagName("username");
            XmlElement xe = (XmlElement)xnl[0];
            cachConf.Username = xe.InnerText.ToString();
            xnl = doc.GetElementsByTagName("password");
            xe = (XmlElement)xnl[0];
            cachConf.Password = xe.InnerText.ToString();               

            Cache.Insert("cachConf", cachConf, 
                new System.Web.Caching.CacheDependency(
                    HttpContext.Current.Request.PhysicalApplicationPath + "MyConf.xml"),
                    DateTime.Now.AddMinutes(60), TimeSpan.Zero,
                    System.Web.Caching.CacheItemPriority.Default,
                    new System.Web.Caching.CacheItemRemovedCallback(
                        CacheItemRemovedCallBack));
        }
        LabelUsername.Text = cachConf.Username;
        LabelPassword.Text = cachConf.Password;            
    }

    private void CacheItemRemovedCallBack(string key, object value, CacheItemRemovedReason reason)
    {
        //Response.Write("Hello world"); 
    }

Вы можете сохранить учетные данные во вторичном файле конфигурации, на который ссылается web.config, следующим образом:

<appSettings file="AppSettings.config"/>

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

Проблема 1. Изменения среды выполнения. Решение, которое Microsoft надеется применить к этому типу проблемы, состоит в том, чтобы просто оставить веб-сервер без состояния. Когда приложение ASP.NET перезапускается, оно позволяет существующим запросам завершать запуск новых запросов в новом процессе. Дополнительные сведения см. В разделе Повторное использование процессов IIS. Изменение в web.config перезапускает рабочий процесс, но пользователи этого не заметят (если вы не сохраните состояние в процессе веб-сервера). Это дизайн MS.

Если вы хотите отслеживать изменения без перезапуска процесса, вам нужно что-то другое, кроме поведения web.config по умолчанию. В качестве примера можно привести файлы проекта системы круиз-контроля. У них есть компонент, который сопоставляет объекты с xml и обратно, с его помощью вы можете использовать класс FileSystemWatcher для отслеживания изменений.

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

Чтобы было круто, используйте инверсию контейнера управления, потому что это именно то, что они делают. Мне нравится autofac (потому что мне нравится ссылка на Филипа К. Дика), но замок Виндзор великолепен.

Теперь, если вы говорите об изменениях в базах данных или поставщиках данных на лету, возможно, конфигурация не подходит. Если вы составляете отчеты по x базам данных типов y, вам нужен центральный репозиторий этой информации о базе данных, а файл конфигурации - неподходящее место, и контейнер IOC не является правильным решением.

Как предлагал Осадный, попробуйте Castle Windsor:

http://www.castleproject.org/container/

Вы делаете инверсию управления вручную. Виндзор снимет с вас ношу.