Каковы плюсы / минусы выбора между статическими классами и классами доступа к данным в веб-приложении?

Question

Я прочитал несколько других вопросов по этой теме ( здесь , здесь и здесь ), но еще не нашел хорошего ответа.Я уже разработал свою справедливую долю слоев доступа к данным и лично предпочитаю использовать экземпляры классов вместо статических классов.Тем не менее, это скорее личное предпочтение (мне нравится тестировать свои бизнес-объекты, и этот подход облегчает макетирование DAL).Я использовал статические классы для доступа к базе данных раньше, но я всегда чувствовал себя немного неуверенно в целесообразности такого дизайна (особенно в среде ASP.NET).

Может ли кто-нибудь рассказать о хороших плюсах / минусах в отношении этих двух подходов к разработке классов доступа к данным с поставщиками ADO.NET (без ORM), в частности, в приложении ASP.NET.Не стесняйтесь, если у вас есть несколько более общих советов по статическим и инстансным классам.

В частности, меня беспокоят следующие проблемы:

1. Потоки и параллелизм
2. Масштабируемость
3. Производительность
4. Любые другие неизвестные

Спасибо!

Answer 1

Статические подходы обычно имеют одно и только одно главное преимущество: они просты в реализации.

Подходы, основанные на экземплярах, выигрывают для:

1. Потоки и параллелизм -Вам не нужна никакая / такая большая синхронизация, поэтому вы получаете лучшую пропускную способность
2. Масштабируемость - те же проблемы, что и выше
3. Perf.- Те же проблемы, что и выше
4. Тестируемость - это гораздо проще проверить, так как макетирование экземпляра легко, а тестирование статических классов хлопотно

Статические подходы могут выиграть:

1. Память - у вас есть только один экземпляр, поэтому занимает меньше места
2. Согласованность / совместное использование - легко сохранить единичный экземпляр в соответствии с самим собой.

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

Answer 2

Мое общее чувство таково: зачем создавать экземпляры, если вам это не нужно?

Я использую статические классы, когда не нужно использовать несколько экземпляров и нет необходимости в членах экземпляра.Что касается DAL, дело в том, что есть только один.Зачем создавать его экземпляр, если в нем нет значения?

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

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

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

Answer 3

Для меня главная причина в том, что мне не нужно сохранять состояние этого объекта DAL.Состояние используемых им объектов не охватывает область метода, в который они встраиваются.Таким образом, зачем хранить несколько экземпляров объекта, если они все одинаковы?

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

Опять же с последними версиями .NET Framework, TransactionScope (что может стать одной из причин для управления своими соединениями самостоятельно)перейти на бизнес-уровень, который позволит вам присоединить несколько вызовов к DAL в пределах одной области.

Таким образом, я не вижу убедительного случая для создания и уничтожения (или кэширования) экземпляров DAL.

Answer 4

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

 List<Entity> tableRows = SQL.Read(new SearchCriteria(), new Table());

Все порождает статический класс SQL, и это делает мой код намного проще.