EJB3 Бизнес-делегаты

Question

Есть ли причина для делегирования при использовании EJB3? Потому что единственное реальное преимущество, которое я вижу от делегата, состоит в том, что он позволяет скрыть поиск и доступ к деталям архитектуры EJB. Ну, это также обеспечивает некоторую развязку, но это в основном не используется, imho. С EJB3 у нас есть инъекция, так что теперь я могу просто создать переменную с аннотацией @EJB и использовать ее как есть. Мне все еще нужны делегаты? Потребляет ли этот инъекционный ресурс? Я имею в виду, если я использую его в bean-компонентах, управляемых запросами JSF, может быть, все-таки лучше использовать делегаты, просто чтобы уменьшить эти вызовы внедрения?

Спасибо!

Answer 1

Давайте вспомним силы исходного шаблона бизнес-делегата :

• Клиентам уровня представления необходим доступ к бизнес-услугам.
• Разным клиентам, таким как устройства, веб-клиенты и толстые клиенты, необходим доступ к бизнес-услугам.
• API бизнес-сервисов могут меняться по мере развития бизнес-требований.
• Желательно минимизировать связь между клиентами уровня представления и бизнес-сервисом, таким образом скрывая основные детали реализации сервиса, такие как поиск и доступ.
• Клиентам может потребоваться реализовать механизмы кэширования информации о бизнес-сервисах.
• Желательно уменьшить сетевой трафик между клиентскими и бизнес-сервисами.

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

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

Мне нравится анализ от Адама Бьена : один из пунктов о связи, который до сих пор не решен естественным образом, это исключения . Исключения теперь не проверены, но все еще существуют. Предполагается, что клиент полностью защищен от исключений EJB или нет, снова зависит от сил, присутствующих в проекте.

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

PS: из моего собственного опыта, внедрение ресурсов никогда не было проблемой производительности (у меня всегда была более серьезная проблема с производительностью в другом месте, чем за миллисекунду, затраченную на внедрение :)

Answer 2

Бизнес-делегаты были всего лишь хаком, чтобы скрыть весь кладж с помощью поиска JNDI и всей связанной очистки и отлова ошибок. Внедрение ресурсов пришло в J2EE через Gavin Kings Seam, который в основном следует принципу «как можно меньше слоев» и конфигурации в одном месте. Так что забудьте об этих старых шаблонах и просто используйте нормальную ОО-систему.

Мои 2 цента.

Answer 3

Ну, на самом деле я не совсем понимаю эти моменты.

Клиентам уровня представления необходим доступ на бизнес-услуги.

Уровень представления в случае JSF является управляемым компонентом, не так ли? Если это так, то эта проблема решается путем инъекции. Верно?

Различные клиенты, такие как устройства, Нужны веб-клиенты и толстые клиенты доступ к бизнес-сервису.

У меня нет устройств и толстых клиентов. А что такое веб-клиент? Разве это не тот же уровень представления сверху? Если это так, то у нас та же ситуация, что и выше.

API бизнес-сервисов могут изменяться как бизнес-требования развиваются.

Я не могу понять, как на самом деле могут помочь делегаты при изменении API. Ну, конечно, если это всего лишь некоторые незначительные изменения, которые вы можете обработать, просто изменив тип некоторых переданных параметров или используя только определенное поле вместо какого-либо параметра, тогда это может помочь, но я не думаю, что такие ситуации случаются часто, и это не так сложно и может быть даже лучше изменить вызов метода из управляемого компонента или чего-то еще. Пока серьезные изменения потребуют в любом случае изменить вызов метода.

Клиентам может потребоваться реализовать кэширование механизмы для делового обслуживания информация.

Кэширование - это сложный вопрос, так как я не знаю, что кешировать и как это сделать :) Означает ли это, что я могу создать некоторую переменную, которая будет хранить некоторые результаты, и использовать вызов ejb только тогда, когда эта переменная вызывается первый раз? Это хорошая практика для таких общих ресурсов, как делегат должен быть?

желательно уменьшить сеть трафик между клиентом и бизнесом услуги.

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