Какие вопросы необходимо учитывать при определении места размещения бизнес-логики в приложении Java EE?

Question

В частности, уровень EIS (базы данных) по сравнению с использованием веб-уровня с POJO и легкой структурой или стандартным уровнем бизнес-логики с использованием EJB. Кроме того, могут быть и другие варианты, кроме тех, о которых я не знаю. По сути, это соображения по проектированию бизнес-логики с EJB-компонентами и без них. Рекомендации по использованию одной альтернативы над другой.

Это было бы в контексте приложения Java EE, развернутого на сервере приложений.

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

Я думаю по следующим направлениям:

• Если у вас есть таблицы базы данных с миллионами строк, посмотрите, как поместить бизнес-логику в хранимые процедуры и триггеры.
• Если у вас есть простая бизнес-логика для приложения, посмотрите на использование POJO для бизнес-логики.

Answer 1

Я бы попробовал ответить на следующие вопросы:

• Требуется ли высокая производительность?
• что такое инфраструктура? один сервер? кластер? облако?
• у меня ограниченная память?
• приложение будет использовать / управлять тысячами записей, миллионами или миллиардами?
• как долго это будет жить? 5 лет, 20 лет?
• Насколько велико приложение, сколько разработчиков будет над ним работать?
• Разработчики знакомы с технологией (то есть фреймворком)?

Я думаю, что для больших приложений с несколькими разработчиками, работающими в одно и то же время и планирующими работать в течение длительного периода времени, это большое преимущество для использования архитектуры WEB/EJB/JPA, она генерирует код, который легко обслуживать и очень легко читать. Но если приложение будет работать с несколькими миллионами записей, вероятно, лучше подумать о технологии / среде с лучшей производительностью.

Answer 2

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

Если у вас есть интересная доменная логика, рассмотрите возможность использования JPA с богатыми отношениями и поведением в ваших сущностях (модель домена - см. Дизайн, управляемый доменом). Это был мой любимый путь в течение долгого времени.

Если ваше приложение представляет собой простое приложение CRUD (обслуживание данных без большой глубины предметной логики), вы, вероятно, можете обойтись без JPA (но я бы лично использовал его для удобства) и самым простым способом выполнения основных функций., Минимальная бизнес-логика может быть достигнута в "сценариях транзакций" на уровне сервиса.

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

Вы можете смешивать и сочетать вышеперечисленное, ИМО. Но я прагматик, а не пурист.

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