Лучшая практика для сложных общих / статических членов

Question

Я взял на себя приложение ASP.NET и нашел его в нескольких классах приложения. Программисты ранее определили несколько общих / статических переменных, которые действуют как «сложные перечисления» во всем приложении. Как довольно новый программист, это не похоже на лучшую практику.

Вот пример:

Public Shared SecureCommentsWrite As New Task("Secure Comments Write")
Public Shared SecureCommentsRead As New Task("Secure Comments Read")
Public Shared EditEmergencyContact As New Task("Edit Emergency Contact")
Public Shared DisplayPersonalReferences As New Task("Display Personal References")
Public Shared EditPersonalReferences As New Task("Edit Personal References")

Конструктор берет описание, затем загружает ключ ID из базы данных, используя хранимую процедуру (база данных - SQL Server.) Это кажется хорошей идеей, поскольку мы развертываем это приложение в нескольких базах данных и хотим убедиться, что мы загружаем Идентификационный ключ, который находится в этой базе данных в случае его изменения. Однако, поскольку в приложении их буквально сотни, первая загрузка занимает некоторое время.

Считается ли это наилучшей практикой, а если нет, то что считается наилучшей практикой для подобной ситуации?

Answer 1

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

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

в этих случаях обратите внимание, что SqlDataReader, вероятно, будет лучше, чем DataSet, потому что вам нужен только пересылка, только быстрый доступ к данным только для чтения.

это пока все с моей стороны ;-)

Answer 2

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

Тем не менее, если инициализация этих полей вызывает заметное замедление (и поскольку оникаждый из них попадает в базу данных, это не удивительно), есть несколько методов, которые вы можете использовать, чтобы сократить время загрузки.Очевидное решение состоит в том, чтобы использовать ленивую загрузку - другими словами, не попадайте в базу данных до тех пор, пока вам это не понадобится!Это, по сути, амортизирует стоимость попадания в базу данных для инициализации этих полей в течение всего срока службы программы, давая вам гораздо более быстрый запуск в обмен на несколько более низкую производительность в других местах.100 или 1000 из них одновременно, это тоже не может быть идеальным решением;в этом случае вы просто переместили огромную задержку, а не разбили ее.

Другая идея заключается в повышении эффективности SQL, ответственного за получение этих идентификаторов.Вы можете написать один Initialize() метод, который выполняет один запрос, чтобы вытащить все нужные вам идентификаторы, а не делать это в 100 различных запросах.Это почти наверняка будет быстрее.

Answer 3

Не рекомендуется запускать запросы к базе данных / хранимые процедуры в конструкторе объектов или любые другие, возможно, трудоемкие операции. Если что-то не так во время инициализации объекта Task, так как он объявлен как статический / разделяемый член, он может вызвать исключение TypeInitializationException, и ваше приложение станет непригодным для использования.

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

Answer 4

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

Он должен загрузить (один раз) DataTable или DataSet, представляющий весь список Task элементов.Это может быть сделано конструктором или [лениво], когда выполняется первый запрос для экземпляра.

Вместо того, чтобы каждый раз нажимать на db, метод фабрики CreateInstance() должен затем обращаться к предварительно загруженным данным дляэто нужно.