EJB Advocate: EJB 2.x умерла? (исходники)

Теория: Долой старое, да здравствует новое!

@Entity @Table(name="CUSTOMER") public class Customer implements Serializable { 	 private int id; private String name; private Order openOrder; 	 public Customer () { super(); } 	 @Id @Column(name="CUST_ID") public int getId() { return id; } public void setId(int id) { this.id = id; } 	 @Column(name="NAME") public String getName() { return name; } public void setName(String name) { this.name = name; } 	 @OneToOne(cascade=CascadeType.ALL , fetch=FetchType.EAGER ) @JoinColumn(name="OPEN_ORDER_ID",referencedColumnName="ORDER_ID") public Order getOpenOrder() { return openOrder; } public void setOpenOrder(Order openOrder) { this.openOrder = openOrder; }  }

@PersistenceContext (unitName="db2") EntityManager em; try { Customer c = (Customer)em.find( Customer.class, new Integer(customerId) ); Order o = c.getOpenOrder(); return o; } catch (EntityNotFoundException e) { throw new CustomerDoesNotExist(customerId); }

Опыт: Не торопитесь, нужно учитывать компромиссы

1. JPA-компоненты управления данными - это не POJO
   
   Вначале Вы упомянули, что просто создаете POJO и аннотируете его (в числе прочего используя @entity) для создания компонента в стиле JPA. Все правильно. Но справедливости ради надо сказать, что большинство не считает механизм персистенции основанным на POJO, пока он не может быть использован с существующим (не модифицированным) простым Java-классом.
   
   Можно также вспомнить времена EJB 1.x, когда компоненты управления данными были больше похожи на POJO. Переменные экземпляра объявлялись как часть реализации компонента, который был конкретным классом. Вы "аннотировали" класс путем объявления его EJB-компонентом управления данными и реализовали методы управления жизненным циклом, такие как ejbLoad() и ejb Store() (или оставляли их для инструментальных средств развертывания). Одной из причин отказа от них явилось то, что они загружали CMP-поля по принципу все или ничего. Подход EJB 2.x разрешает гибко улучшать производительность, например, отображать методы get() на курсор базы данных или реализацию потока, уменьшая количество преобразований. JPA разрешает "ленивую" загрузку свойств через аннотацию, но как мы увидим далее, этот подход создает свои собственные проблемы, если полагать, что логический объект является POJO-объектом.
   
   
2. JPA и EJB 2.x не требуют создавать подкласс (расширять) какого-либо конкретного класса
   
   Затем Вы упомянули, что при использовании JPA ничего не нужно "наследовать", подразумевая, что логические объекты EJB 2.x это делают. Такое предположение ошибочно. Представьте типичное объявление класса компонента управления данными в EJB 2.x:
   
   

   public abstract class CustomerBean implements EntityBean ...

   
   Класс (абстрактный или конкретный), реализующий интерфейс, на самом деле не наследует ничего из интерфейса, который он реализует. Реализация интерфейса - это просто маркер того, что класс может выполнять данную роль в приложении, аналогично действию, для которого предназначена аннотация @entity.
   
   Эта отличительная особенность очень важна, поскольку в том, что касается реализации, Java поддерживает только одинарное наследование. Вы можете расширить только один класс и наследовать его реализации методов. Вы можете реализовать столько интерфейсов, сколько пожелаете.
   
   А поскольку EJB 2.x-компоненты управления данными являются абстрактным классом, нет необходимости реализовывать какие-либо из различных методов жизненного цикла EJB, связанных с интерфейсом EntityBean, например, ejbLoad() и ejbStore(). Эти реализации могут быть возложены на инструментальные средства развертывания, предоставляемые поставщиками программного обеспечения.
   
   
3. JPA-компоненты управления данными не поддерживают несколько представлений
   
   Далее Вы заметили, что не нужно создавать интерфейс или home в JPA-компонентах. Это правда. Но такая простота есть следствие компромисса: Вы напрямую обращаетесь к классу реализации. Ограничение заключается в том, что Вы получаете только одно представление компонента. Java-интерфейсы являются мощными в том плане, что можно предоставить представления компонентов реализации, настроенные под требования клиента. EJB 2.x-компоненты управления данными поддерживают концепцию отделения реализации от интерфейсов. Например, можно предоставить как удаленное, так и локальное представление логического объекта.
   
   Почему Вы хотите предоставить удаленный интерфейс к EJB-компоненту управления данными, если наилучшей известной методикой является использование фасада? В предыдущей статье EJB Advocate мы рассказали, как использовать специализированные home-методы компонентов управления данными для выполнения роли встроенного фасада. Поскольку фасад часто используется удаленно, можно было бы предоставить удаленный домашний интерфейс, включающий один или несколько специализированных методов, например:
   
   

   public interface CustomerHome implements EJBHome { CustomerData ejbHomeGetOpenOrderForCustomer(int customerId) ... }

   
   Обратите внимание на то, что этот удаленный интерфейс не имеет каких-либо методов create() или find(). Это преднамеренное их отсутствие гарантирует, что к экземпляру логического объекта Customer никогда нельзя обратиться удаленно. Локальный и домашний интерфейсы к этой же реализации компонента предоставляли бы методы create и find вместе с соответствующими методами get и set (которые, возможно, представляют собой CMR, как описано в еще одной статье EJB Advocate).
   
   И, как уже говорилось, большинство инструментальных средств для EJB (например, программное обеспечение IBM Rational Application Developer for WebSphere) генерирует интерфейсы и home за один шаг при помощи программы Wizard. Некоторые даже предоставляют возможность начать с реализации компонента (например, POJO) и создавать методы для интерфейса и home по мере необходимости.
   
   
4. JPA-компоненты управления данными встраивают детали реализации в Ваши POJO-объекты
   
   Еще одно "преимущество" JPA, упомянутое Вами, - возможность пропустить создание отдельного дескриптора развертывания и действия по отображению для конкретного поставщика программного обеспечения. Все это хорошо (особенно в том, что касается стандартных отображений на хранилища реляционных данных), но здесь имеет место компромисс. Вы встроили детали реализации в код, что сделало объект еще менее похожим на простой POJO, к которому Вы, по-видимому, стремитесь.
   
   Одной из наилучших функциональных возможностей EJB 2.x-компонентов управления данными является то, что при развертывании можно изменить детали реализации персистенции данного бизнес-объекта абсолютно независимо от провайдера компонента. Нет причин, по которым провайдер не может принять аналогичный стандартный набор аннотаций для отображения как часть дескриптора развертывания в стиле EJB 2.x, чтобы упростить действия по отображению.
   
   
5. JPA-компоненты управления данными все еще лучше использовать за фасадом
   
   Наконец, Вы правильно отметили, что имеется только одна реализация EntityManager, которая устраняет необходимость выполнять JNDI-поиск и чрезвычайно облегчает использование JPA-компонента управления данными. Однако Вы не упомянули, что если не использовать JPA-компонент в контексте транзакции, необходимо явно сохранять EntityManager для сохранения любых изменений. Еще один аспект JPA, о котором Вы забыли упомянуть: если объявить для компонента "ленивую" загрузку в аннотациях и затем отключить от контекста (то есть, конец транзакции), то нетронутые поля становятся неопределенными.
   
   Необходимость явного управления контекстом транзакций могла бы усложнить программную модель JPA. Поэтому до сих пор наилучшей методикой остается использование сессионного фасада (в новом стиле EJB 3 или в старом EJB 2.x). Если Вы выберете возврат POJO из фасада, то Вам придется установить значение загрузки в "eager" (активную) или затронуть все поля в JPA-сущности. При использовании специализированных home-методов EJB 2.x сессия абсолютно не нужна.
   
   

Заключение