EJB3 бизнес

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

Спасибо!

3 6
java-ee jsf ejb-3.0

3 ответа:

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

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

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

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

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

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

7

Бизнес-делегаты были просто хак, чтобы скрыть весь kludge с поисками JNDI и всеми связанными очистками и отловом ошибок. Закачка ресурсов поступила в J2EE через шов Гэвина Кингса, который в основном следует принципу "как можно меньше слоев" и "вся конфигурация в одном месте". Так что забудьте об этих старых шаблонах и просто используйте нормальное OO think.

Мои 2 цента.

1

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

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

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

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

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

API бизнес-служб могут изменяться следующим образом: бизнес-требований.

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

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

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

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

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

0