C# статический класс базы данных?
Я понял!
Мне пришлось динамически определять побочный эффект, но, похоже, он работает нормально. Вот что я сделал:
def setUp(self):
# Setup the content of the config files for the tests
json.load = MagicMock(side_effect=file_content)
# Opening a file returns the name of the file
def get_mock_context(filename):
mock_context = MagicMock()
mock_context.__enter__.return_value = filename
mock_context.__exit__.return_value = False
return mock_context
builtins.open = MagicMock(side_effect=get_mock_context)
Таким образом, возвращаемое значение представляет собой макет, в котором есть методы __enter__ и __exit__, возвращающие именно то имя файла, которое я передал вызову open. [115 ]
8 ответов
Если я понимаю, класс базы данных имеет некоторые свойства, которые хранят результат запроса? Если так, Вы не можете сделать их статичными, так как это не ориентировано на многопотоковое исполнение. Если бы результат запроса хранится в этих свойствах, что произошло бы, если второй запрос выполнится прямо после первого? Это было бы сохранено в той же статической переменной. То же идет для веб-приложения: результат другого пользователя, просматривающего сайт, изменил бы результаты первого пользователя.
Править: Подводя итоги, НЕ делайте класс статичным при хранении результата запросов в статических переменных, особенно не, когда класс используется в веб-сайте, поскольку значение свойств будет совместно использовано среди всех посетителей веб-сайта. Если 20 посетителей сделают запрос одновременно, то посетитель 1 будет видеть результаты запроса 20-х посетителя.
В Вашем определенном примере я отговорил бы от создания статичного класса: Вы сохраняете состояние в классе Базы данных, и путем создания класса статичным, то состояние будет совместно использовано среди всех классов с помощью Базы данных. В Вашей текущей установке каждый экземпляр Базы данных сохраняет свое собственное состояние, таким образом, нет никакой проблемы с вызовами Базы данных, вмешивающимися друг в друга.
При рефакторинге класса Базы данных для возврата наборов данных при выполнении вызова метода, Вы были бы прекрасным созданием его статичный: не было бы никакой информации с сохранением информации, оставленной в классе Базы данных.
Но с тех пор дело обстоит не так: нет, не делайте класс статичным.
Это зависит от того, какая база данных или ORM, который Вы используете. Но по моему опыту это походило на хорошую идею, но закончилось shafting меня. Вот то, как это сделало для меня в LINQ-SQL:
У меня был класс репозитория, который имел статическую переменную к контексту данных. Это работало сначала, но когда я должен был сделать намного больше классов репозитория, я закончил тем, что получил ошибки, когда я взломал вперед. Оказывается, что контекст данных в кэшах LINQ-SQL все результаты и нет никакого способа обновить их. Таким образом, если Вы добавили сообщение в таблице в одном контексте, это не обнаружится в другом, это кэшировало ту таблицу. Решение состояло в том, чтобы удалить статический модификатор и позволить репозиторию создать контекст в конструкторе. Так как классы репозитория были созданы, поскольку они использовались, свежий новый контекст данных - также.
Вы могли утверждать, что статические переменные оставляют меньше места в памяти, но место для контекста данных является довольно маленьким для начала и будет собрано "мусор" в конце.
В дополнение к другим комментарии о потокобезопасности там также проблема распараллеливания. В Вашем случае Вы не сможете открыть несколько соединений с базой данных одновременно, и Вы не сможете выполнить несколько параллельных запросов, даже если потокобезопасность результатов не будет проблемой.
Таким образом, я соглашаюсь с другими, не делайте статический класс из него.
Создание статичного класса может быть удобным, но создание новых экземпляров его, вероятно, не будет дорогой операцией, таким образом, вероятно, не будет очень для получения мудрый производительностью также.
Править:
Я видел в комментарии, что Вы хотите использовать свой класс на веб-сайте. В этом случае Вы ДЕЙСТВИТЕЛЬНО не должны делать этого. Со статическим классом базы данных Вы только сможете безопасно служить одному запросу в любое время, и это не то, что Вы хотите.
Если у Вас есть статический метод, необходимо отслеживать экземпляры, когда Вы открываете и закрываете базу данных.
Таким образом, то, что Вы, вероятно, хотите сделать, имеют статический метод, названный экземпляром или текущим экземпляром. И в Вас создают новый экземпляр Вашего класса дб, возвращая его в статическом методе.
Вопреки сообщению ответа. Я создал webframework со статическим доступом к базе данных, он работает отлично и дает высокую эффективность.
Можно проверить исходный код по http://www.codeplex.com/Cubes
Если Вы просто выполняете запросы против DB, то да делают это статичным. Только необходимо создать экземпляр, если этот объект должен сохранить своего рода состояние.
Ваши методы, хорошие для статического использования. Я думаю, Вы не испытываете затруднений для преобразования их в статические методы на данный момент.
но позже возможно, необходимо будет справиться с транзакцией. отъезд управления транзакциями к классу, экономит много времени, я думаю. и этот сценарий является лучшими соответствиями с нестатическим классом.