Делегаты бизнеса EJB3
Есть ли какая-либо причина того, чтобы сделать делегата при использовании EJB3? Поскольку единственная реальная выгода, которую я вижу от делегата, - то, что это позволяет скрывать поиск и данные доступа архитектуры EJB. Хорошо это также обеспечивает некоторое отделение, но это главным образом не использовано, по моему скромному мнению. С EJB3 у нас есть инжекция поэтому теперь, я могу просто создать переменную с @EJB аннотацией и использовать ее как есть. Мне все еще нужны делегаты? Этот инжекционный ресурс использует? Я имею в виду, использую ли я его в управляемых компонентах запроса JSF, может быть, еще лучше использовать делегатов только для уменьшения этих инжекционных вызовов?
Спасибо!
3 ответа
Давайте вспомним силы исходного шаблона бизнес-делегирования :
- Клиентам уровня представления нужен доступ к бизнес-услугам.
- Различным клиентам, таким как устройства, веб-клиенты и толстые клиенты, необходим доступ к бизнес-сервисам.
- API-интерфейсы бизнес-сервисов могут изменяться по мере развития бизнес-требований.
- Желательно свести к минимуму связь между клиентами уровня представления и бизнес-службой, таким образом скрывая основные детали реализации службы, такие как поиск и доступ.
- Клиентам может потребоваться реализовать механизмы кэширования информации о бизнес-услугах.
- Желательно уменьшить сетевой трафик между клиентскими и бизнес-сервисами.
Все эти силы актуальны и сегодня - они не обязательно присутствуют в каждом проекте, но могут .
Основное изменение заключается в том, что нам не нужен бизнес-делегат для минимизации связи (выделенный курсивом). Внедрение зависимостей решило проблему поиска и доступа.
Мне нравится анализ Адама Бьена : один из вопросов о связи, который до сих пор не решен естественным образом, - это исключения . Исключения теперь не отмечены, но все еще существуют. Предполагается, что клиент будет полностью защищен от исключений EJB или нет, снова зависит от сил, присутствующих в проекте.
В случае, если шаблон бизнес-делегата был введен для решения проблемы поиска и доступа (что, как я подозреваю, имело место для многих проектов), он нам больше не нужен. Если бизнес-делегат был предназначен по другим причинам, это все еще имеет смысл.
PS: по моему собственному опыту, инъекция ресурсов никогда не была проблемой производительности (у меня всегда были более серьезные проблемы с производительностью в другом месте, чем миллисекунды, взятые на инъекцию :)
Ну, на самом деле я не совсем понимаю эти моменты.
Клиентам презентационного уровня необходим доступ к бизнес-сервисам.
Уровень представления в случае JSF - это управляемый компонент, не так ли? Если это так, то эта проблема решается с помощью инъекции. Верно?
Различным клиентам, таким как устройства, веб-клиенты и толстые клиенты, требуется доступ к бизнес-сервисам.
У меня нет устройств и толстых клиентов. А что такое веб-клиент? Разве это не тот же уровень презентации сверху? Если это так, то у нас такая же ситуация, как и выше.
API бизнес-сервисов могут изменяться по мере развития бизнес-требований.
Я не могу понять, как на самом деле делегаты могут помочь при изменении API. Ну, конечно, если это всего лишь незначительные изменения, с которыми вы можете справиться, просто изменив тип некоторых переданных параметров или используя только определенное поле вместо какого-либо параметра, тогда это может помочь, но я не думаю, что такие ситуации случаются часто, и это не так сложно, и может быть даже лучше изменить вызов метода из управляемого bean-компонента или чего-то еще. А серьезные изменения в любом случае потребуют изменения вызова метода.
Клиентам может потребоваться реализовать механизмы кеширования для информации бизнес-службы .
Кеширование - сложный вопрос, так как я не знаю, что кэшировать и как это делать :) Означает ли это, что я могу создать некоторую переменную, которая будет хранить некоторые результаты и использовать вызов ejb только тогда, когда эта переменная вызывается для первый раз? Это хорошая практика для таких общих ресурсов, какой должен быть делегат?
Желательно уменьшить сетевой трафик между клиентскими и бизнес-службами .
Как делегаты могут уменьшить сетевой трафик? По той же методике с переменной, которая хранит какие-то значения?
Бизнес-делегаты были просто хаком, чтобы скрыть всю эту мороку с поиском JNDI и всеми связанными с этим очистками и отлавливанием ошибок. Инъекция ресурсов пришла в J2EE через Gavin Kings Seam, который в основном следует принципу "как можно меньше уровней, как это возможно, и вся конфигурация в одном месте". Так что забудьте об этих старых паттернах и просто используйте нормальное ОО мышление.
Мои 2 цента.