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

Question

Я создаю небольшой веб-сайт для развлечения / обучения с использованием довольно стандартного многоуровневого дизайна Web / Service / Data Access.

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

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

Недостатки:

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

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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

Answer 6

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