Сколько EJB слишком много?

Question

В настоящее время я разрабатываю большую часть программного обеспечения на JavaEE. Мы следовали общим рекомендациям JavaEE, в которых говорится, что каждый связанный набор операций должен переходить в их собственный EJB. В настоящее время у нас есть более 275 различных классов EJB (фаз сессий без состояния). Это число, скорее всего, будет расти, по крайней мере, удвоить это число.

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

Мы используем Glassfish v2 с JavaEE 5 на солнечной Java-платформе Java 6, поэтому советы по этой конкретной платформе будут наиболее ценными.

Answer 1

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

EJB - это просто классы, поэтому вам не о чем беспокоиться, кроме общей нагрузки, которая ортогональна количеству развернутых вами EJB.

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

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

Answer 2

(Есть ли способ, что я могу сказать «любой вообще» без отвергнуто?)

На серьезной ноте, используйте столько, сколько нужно. Мое эмпирическое правило (как для EJB, так и для классов в целом), если вы не можете полностью описать, что вещь делает в имени класса около трех слов, у вас это слишком много.

Что касается производительности, я подозреваю, что если система начинает страдать от «слишком большого количества EJB», у вас проблемы с гораздо большими проблемами.

Answer 3

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

Гранулярность компонента, очевидно, зависит от домена.

Предположим, что вы моделировали (довольно старомодный) компьютер с EJB. Резисторы, транзисторы, катушки и т. Д .: Это пожо. Чипы и платы являются компонентами. Сборка - EAR.

Гранулярность интерфейса должна отражать функцию компонента.

Answer 4

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

Я не думаю, что системе нужны сотни EJB. В то время как я был также вовлечен в приложение с 90 EJB, это был кошмар: < Не было никакой возможности тестирования, и развертывание также является огромной задачей.