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

Question

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

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

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

Я имею в виду вдоль линий:

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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