Сколько EJBs - слишком многие?
Вы можете использовать пакет для встраивания файлов, который использует Template Haskell для встраивания файлов.
4 ответа
EJB должны быть мелкозернистыми, чтобы не было проблем с тем, что вы делаете, если вы последовательны в своем дизайне
EJB - это просто классы, поэтому не о чем беспокоиться, за исключением общей нагрузки, которая ортогональна количеству развернутых EJB.
Если вы беспокоитесь о производительности, включите некоторый мониторинг или другую производительность. метрики и посмотрите, как идут дела, когда вы добавляете новые функции.
В конце концов, вы бы предпочли поддерживать меньше классов с множеством методов или множество классов с меньшим количеством методов? Я знаю, какой из них я выберу.
(Есть ли способ, которым я могу сказать «любой вообще», не будучи проголосованным?)
На серьезной ноте, используйте столько, сколько вам нужно. Мое эмпирическое правило (как для EJB, так и для классов в целом), если вы не можете полностью описать, что делает эта вещь, в названии класса из трех слов, у вас слишком много работы.
Что касается производительности Я подозреваю, что если система начинает страдать от «слишком большого количества EJB-компонентов», у вас где-то гораздо большие проблемы.
EJBs are components and not classes and you should think of them in that term and express your system design appropriately.
The granularity of the component is obviously domain dependent.
Assume you were modeling a (fairly old fashioned) computer with EJBs. Resistors, transistors, coils, etc.: These are pojos. Chips and Boards are Components. The assembly is the EAR.
Interface granularity should reflect component function.
EJB - это не просто обычный экземпляр класса. Требуется дополнительное обслуживание в контейнере, пуле экземпляров и т. Д. Многие EJB требуют много ресурсов на сервере.
Я не думаю, что системе нужны сотни EJB. Хотя я также работал с приложением с 90 EJB, это был кошмар: <Тестируемости не было, а развертывание - тоже огромная задача.