Статический класс базы данных С#?

Question

У меня есть класс базы данных, который содержит следующие методы:

• public bool ExecuteUDIQuery(строковый запрос) // UDI = Обновить Удалить Вставить
• public bool ExecuteSelectQuery (строковый запрос)
• public bool ExecuteSP(string sp, string[,] parms)
• public int ExecuteSPReturnValue(string sp, string[,] parms)

Результаты методов хранятся в частных наборах данных или таблицах данных.Эти объекты определяются как геттеры.

Существует около 10 классов, использующих класс базы данных.Каждый класс создает объект класса Database.Теперь я думал сделать класс базы данных статическим.Это хорошая идея?Если да, то почему?Нет, почему бы и нет?

Answer 1

Насколько я понимаю, у класса базы данных есть какие-то свойства, в которых хранится результат запроса?Если это так, вы не можете сделать их статическими, поскольку это не является потокобезопасным.Если результат запроса хранится в этих свойствах, что произойдет, если второй запрос будет выполнен сразу после первого?Он будет храниться в той же статической переменной.То же самое касается веб-приложения:результат просмотра сайта другим пользователем изменит результаты первого пользователя.

РЕДАКТИРОВАТЬ:Подводя итог, НЕ делайте класс статическим, когда вы сохраняете результаты запросов в статических переменных, особенно когда класс используется на веб-сайте, поскольку значения свойств будут использоваться всеми посетителями вашего веб-сайта.Если 20 посетителей одновременно выполняют запрос, посетитель 1 увидит результаты запроса посетителя 20.

Answer 2

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

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

Но поскольку это не так:нет, не делайте класс статическим.

Answer 3

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

Поэтому я согласен с остальными: не делайте из этого статический класс.

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

Редактировать:
В комментарии я увидел, что вы хотите использовать свой класс на веб-сайте.В этом случае вам ДЕЙСТВИТЕЛЬНО не следует этого делать.Со статическим классом базы данных вы сможете безопасно обслуживать только один запрос в любое время, а это не то, что вам нужно.

Answer 4

Это зависит от того, какую базу данных или ORM вы используете.Но, по моему опыту, это казалось хорошей идеей, но в итоге меня подвело.Вот как это произошло у меня в LINQ-to-SQL:

У меня был класс репозитория, который имел статическую переменную для контекста данных.Поначалу это работало, но когда мне пришлось создать еще много классов репозитория, по мере взлома я получал ошибки.Оказывается, контекст данных в LINQ-to-SQL кэширует все результаты и обновить их невозможно.Таким образом, если вы добавили сообщение в таблицу в одном контексте, оно не будет отображаться в другом, который кэшировал эту таблицу.Решением было удалить модификатор static и позволить репозиторию создавать контекст в конструкторе.Поскольку классы репозитория создавались по мере их использования, то же самое происходило и с новым контекстом данных.

Вы можете возразить, что статические переменные занимают меньше места в памяти, но объем контекста данных изначально довольно мал, и в конце концов он будет утилизирован сборщиком мусора.

Answer 5

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

Вы можете проверить исходный код на http://www.codeplex.com/Cubes

Answer 6

Если вы просто выполняете запросы к БД, то да, сделайте его статическим.Вам нужно создать экземпляр только в том случае, если этому объекту необходимо сохранять какое-то состояние.

Answer 7

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

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

Answer 8

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

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