SessionBeans и CDI vs POJO classes

Question

Я читал учебник JavaEE 6 и, читая разделы SessionBean и CDI, я наткнулся на несколько сомнений.

1) Для того, что я понял, аннотация @EJB вводит SessionBean, что приводит к использованию шаблона Injectency Inject. Я понимаю, что эта схема направлена ​​на отмену ответственности того, кто строит объекты. Таким образом, вместо определенного класса, создающего его собственные зависимости, он получит их в конструкторе. Однако, как аннотация @EJB смягчает проблемы не впрыскивания зависимостей? То же самое касается аннотации @Inject.

2) У меня есть этот класс утилиты (содержит только статические методы), который форматирует дату в несколько форматов (yyyy-MM-dd, dd-MM-yyyy и т. Д.). Лучше ли использовать этот сеанс без статусов для этих методов или я должен сохранить класс Utility? В случае использования EJB для этого, в чем разница между его использованием или использованием компонента с помощью аннотации @Inject?

3) При использовании Injection Dependency имеет смысл использовать шаблоны Service Locator или Factory? (Хотя я видел, что Service Locater регистрируется как анти-шаблон).

Answer 1

1. Нет. Включение зависимостей заключается не только в том, чтобы избежать создания его зависимостей. Это также не позволяет спросить контейнер о его зависимостях. Вместо запроса контейнера для зависимостей, контейнер вставляет зависимости в компонент. Я не понимаю, что вы подразумеваете под «проблемой не впрыскивания зависимостей». Просьба уточнить.

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

3. Нет, это не имеет смысла. Основная цель инъекции Depoendency - заменить использование локатора сервисов и/или фабрики, чтобы контейнер ввел зависимость в компонент. Это то, что делает код легко testablen, потому что вы можете просто вводить поддельные зависимости (mock objects) в bean-компонент в вашем модульном тесте.

Answer 2

@EJB и @Inject смягчить проблему не инъекционным путем ... инъекционного (Дух;!))

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

В большинстве случаев вы можете сделать этот класс утилиты инъекционным через CDI: определить для него интерфейс и создать метод-производитель. Часто даже это излишне, но это зависит от точной протяженности вашего класса и его использования.

С инъекцией у вас все еще есть фабрики (производитель - своего рода завод), но клиент явно не использует фабрику. Клиент заявляет о зависимости, и CDI может использовать «фабрику» (производителя) для удовлетворения этого.