Статические слои в веб-приложении Java

Question

Я создаю небольшой веб-сайт для развлечения/обучения, используя довольно стандартный многоуровневый дизайн Интернет/Сервис/Доступ к данным.

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

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

Есть ли какая-либо причина, по которой этот подход не будет жизнеспособным?Какие проблемы могут возникнуть в дальнейшем?Было бы лучше иметь «фабричный» класс, который мог бы возвращать мне экземпляры классов уровня обслуживания и данных по мере необходимости?

Answer 1

Недостатки:

• Вы не сможете писать модульные тесты, поскольку вы не сможете писать макеты объектов доступа к данным/бизнес-логики для тестирования.
• У вас возникнут проблемы с параллелизмом, поскольку разные потоки одновременно попытаются получить доступ к статическому коду, или, если вы используете синхронизированные статические методы, в конечном итоге потоки будут стоять в очереди, чтобы использовать статические методы.
• Вы не сможете использовать переменные экземпляра, что станет ограничением по мере усложнения кода.
• При необходимости заменить элементы уровня бизнеса или доступа к данным будет сложнее.
• Если вы собираетесь написать свое приложение таким образом, вам лучше использовать язык, предназначенный для такой работы, например PHP.

Вам лучше использовать нестатические классы уровня доступа к бизнесу/данным:

• Использование шаблона Singleton (создание одного экземпляра каждого класса и совместное использование его между потоками)...
• Или создавать экземпляры классов в каждом потоке по мере необходимости.

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

Answer 2

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

Дело вот в чем: есть причина, по которой вам следует следовать «истинному ОО-подходу», точно так же, как есть причина держать руки и ноги внутри аттракциона — это очень весело, пока вы не начнете кровоточить повсюду.

Answer 3

То, как вы это описываете, само по себе не является «неправильным» подходом, но я не вижу проблемы, которую вы пытаетесь избежать.Не можете ли вы просто создать один экземпляр этих бизнес-объектов при запуске сервера и передать их вашим сервлетам по мере необходимости?

Если вы готовы выбросить ОО из окна, возможно, вам также захочется проверить шаблон Singleton.

Answer 4

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

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

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

На самом деле это не проблема «OO-дизайна», а скорее уместность.Почему вы вообще используете Java таким процедурным способом?Конечно, PHP больше подходит для такого типа дизайна (и фактически сэкономит ваше время, поскольку не придется компилировать и развертывать).

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

Answer 5

У вас могут возникнуть трудности с модульным тестированием объектов с архитектурой такого типа.Например, если у вас есть уровень бизнес-объектов, ссылающийся на ваш уровень доступа к статическим данным, может быть сложно протестировать бизнес-уровень, поскольку вы не сможете легко использовать фиктивные объекты доступа к данным.То есть при тестировании вашего бизнес-уровня вы, вероятно, не захотите использовать «настоящие» методы уровня доступа к данным, поскольку они внесут нежелательные изменения в вашу базу данных.Если ваш уровень доступа к данным не был статическим, вы могли бы предоставить макеты объектов доступа к данным на свой бизнес-уровень в целях тестирования.

Answer 6

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