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

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

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

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

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

Спасибо!


c# asp.net data-access-layer class-design
person Kevin Babcock    schedule 20.01.2010    source источник

Ответы (4)


arrow_upward
15
arrow_downward

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

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

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

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

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

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

person Reed Copsey    schedule 20.01.2010
comment
Я думаю, что плюсы намного перевешивают минусы, по крайней мере, на мой взгляд. Что касается потребления памяти, я думаю, что это, вероятно, незначительный недостаток для большинства приложений. - person Kevin Babcock; 28.01.2010
comment
@Kevin Babcock: Лично я почти всегда стараюсь использовать подходы на основе экземпляров. Если мне нужен / нужен статический, я обычно перехожу к синглтону, так как позже его легче адаптировать к многотонному или инстансному подходу (поскольку вы все еще работаете с экземплярами ...) - person Reed Copsey; 28.01.2010

arrow_upward
6
arrow_downward

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

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

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

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

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

person Gabriel McAdams    schedule 20.01.2010
comment
Создание экземпляров имеет большую ценность. Я лично считаю прямо противоположным: переходите в статическое состояние только в том случае, если есть веская причина для статической обработки типа / данных / метода / и т. Д. - person Reed Copsey; 20.01.2010
comment
Мое общее мнение: зачем делать его статичным, если в этом нет необходимости? - person ; 20.01.2010
comment
@yoda и @Reed: Вам кажется, что мой ответ неверен. На ваш взгляд, каковы недостатки статических классов? - person Gabriel McAdams; 20.01.2010
comment
Главный недостаток (и я видел это много раз): по мере того, как со временем все становится сложнее, вы получаете большие монолитные методы, потому что все ваше состояние должно передаваться как аргументы метода, поскольку вы не можете (практически) использовать статические поля для хранения состояния в многопоточном приложении. По мере роста сложности и глубины люди становятся ленивыми, и вместо того, чтобы инкапсулировать что-то в новый метод, все вставляется в строку, копируется, вставляется, зацикливается и т. Д. То же самое может происходить с методами экземпляра, но гораздо проще провести рефакторинг с полями экземпляра /характеристики. - person nitzmahone; 20.01.2010
comment
@Nitz: Это звучит как обратная сторона плохой практики разработки и отсутствия проверки кода. - person Gabriel McAdams; 20.01.2010
comment
@Gabriel McAdams: У статических классов есть немало недостатков для чего угодно, кроме очень простых служебных классов (например, System.Math). Они имеют тенденцию быть более сложными в многопоточных сценариях, поскольку вам нужна дополнительная блокировка. Их сложнее тестировать и высмеивать, когда вам нужно провести сложное тестирование (очень важно для DAL). Они менее гибкие, поскольку нарушают полиморфизм. По сути, статический класс фиксирует вас в фиксированной, жесткой конструкции - в большинстве случаев создание нестатического класса намного проще. В худшем случае, если вам действительно нужна статика, рассмотрите синглтон ... - person Reed Copsey; 20.01.2010

arrow_upward
0
arrow_downward

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

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

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

person Otávio Décio    schedule 20.01.2010
comment
С какими проблемами параллелизма вы столкнулись при вашем подходе? - person Kevin Babcock; 28.01.2010
comment
Как я его настроил, я запускаю по одному объекту подключения для каждого потока. Одна проблема параллелизма, с которой мне пришлось столкнуться, заключалась в том, что вы вставляете новый объект, получаете его сгенерированный первичный ключ (из последовательности или идентификатора) и заполняете значение PK объекта - если вы не будете осторожны, вы в конечном итоге сделаете много вставок и ошибетесь последовательность, испорченная отношениями FK. - person Otávio Décio; 28.01.2010

arrow_upward
0
arrow_downward

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

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

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

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

person Wagner Silveira    schedule 20.01.2010