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

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

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

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

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

8 ответов


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

EDIT: To суммируйте, не делайте класс статическим, когда вы храните результат запросов в статических переменных, особенно когда класс используется на веб-сайте, так как значение свойств будет совместно использоваться всеми посетителями вашего сайта. Если 20 посетителей делают запрос одновременно, посетитель 1 увидит результаты запроса посетителя 20.


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

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

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


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

поэтому я согласен с другими, не делайте из этого статический класс.

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

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


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

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

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


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

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


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


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

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


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

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