Лучший метод для универсальных свойств веб-приложений / глобальных свойств

Question

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

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

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

Я подумал о нескольких способах достижения этого:

1. Сохранение статусов функций в базе данных, а затем на каждомПри обращении к / отображению страницы / меню вызывайте базу данных, запрашивая, скрывать ли страницу / пункт меню.
2. Сохранение статусов функций в базе данных и доступ к ним при запуске приложения, сохранение их во всем приложении, затем онидоступ к нему возможен как и когда.
3. Поместите статусы объектов в веб-конфигурацию, таким образом нам не нужно каждый раз запрашивать базу данных или иметь глобально доступные свойства.

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

С уважением,

Answer 1

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

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

Answer 2

Ответ зависит от того, как часто вы будете изменять статус функций.

Если вы собираетесь устанавливать статусы только один раз, когда вы клонируете сайт и никогда не будете его трогать, перейдите к варианту № 2 (загрузка при запуске приложения).

Если есть вероятность, что вам потребуется изменить статус функций в будущем, перейдите к варианту № 1 (получение статусов при каждой загрузке страницы). Простое чтение данных в БД не повлияет на скорость вашего сайта. БД твой друг, помни, для чего он там. Кроме того, если вам когда-либо потребуется изменить статусы во время работы сайта, этот метод позволяет вам сделать это без перезапуска всего приложения.

Какой бы метод вы в конце концов не решили реализовать, убедитесь, что «приложение широкого» * ​​1008 * хранилища, в котором хранятся настройки, готово к многопоточности. Помните, что каждый запрос страницы будет выполняться в отдельном потоке, и все они получат доступ к одному и тому же ресурсу.

Мое предложение взято из MS ( Многопоточный безопасный шаблон Singleton ):

using System;

public sealed class Singleton
{
   private static volatile Singleton instance;
   private static object syncRoot = new Object();

   private Singleton() {}

   public static Singleton Instance
   {
      get 
      {
         if (instance == null) 
         {
            lock (syncRoot) 
            {
               if (instance == null) 
                  instance = new Singleton();
            }
         }

         return instance;
      }
   }
}

Answer 3

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

И если конфигурация хранится в web.config, она легко доступна администратору, а также легко модифицируется без компиляции или изменения чего-либо.

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