Использование статических методов для взаимодействия с базой данных - есть ли потенциальные проблемы?

Question

Я смотрю на класс, обрабатывающий доступ к базе данных для приложения MVC3 / .Net.

Класс является статическим и предоставляет удобные методы для общих запросов к БД - всевозможные полезные вещи, такие как «GetColumnBValueForColumnA ()», а также гораздо более сложные запросы.Он хорошо проанализирован / оптимизирован для данного решения и области.

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

Это хорошая идея, чтобы сохранять этот класс статичным, или я должен его создавать для каждого вызова базы данных?

Answer 1

Является ли хорошей идеей сохранять такой класс статичным, или я должен его создавать для каждого вызова базы данных?

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

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

Answer 2

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

Это не только два варианта.

Класс должен , а не быть статичным: сделав его статичным , вы упускаете несколько важных преимуществ объектно-ориентированного программирования и практически ничего не получаете.

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

Вот несколько преимуществ:

1. Допустим, вы хотите выполнить модульное тестирование метода, основанного на этом классе доступа к данным.Если вы используете внедренный интерфейс службы вместо непосредственного вызова статического метода, вы можете создать объект Mock, рассказать ему, как себя вести, и позволить методу, который вы тестируете модулем, думать, что он получает реальные данныекогда на самом деле вы просто передаете ему данные, которые хотите протестировать.
2. Допустим, вы захотите кэшировать результаты ваших вызовов доступа к данным.Вы можете внедрить класс кэширования, который обертывает фактический класс, возвращая кэшированные результаты, где это возможно, и вызывая реальные методы доступа к данным, когда кэшированные значения отсутствуют.Ничто из этого не потребует каких-либо изменений в вашем классе доступа к данным.

Я мог бы продолжить.Статические классы убивают вашу гибкость и не имеют практического преимущества в 99% случаев.