Java EE 6 - шаблон «Постоянные доменные объекты» - есть успехи?

Question

У меня есть довольно сложное приложение, использующее POJO, и теперь пришло время перенести его на EJB3.1, чтобы его можно было развернуть в режиме онлайн, получить доступ через службы REST и воспользоваться преимуществами контейнерной среды (постоянство является наиболее важным, но транзакции будуттоже полезно).

Я был далеко от Java EE со времен J2EE и изо всех сил пытаюсь разобраться с "потерей" бинов сущностей.Мне потребовалось некоторое время, чтобы понять, что сущности в EJB3.1 на самом деле не являются Бобами в старом смысле ... :) Я прочитал несколько книг по EJB3, включая «руководство» O'Reilly Enterprise JavaBeans 3.1, все из которых объясняютконцепции и компоненты EJB3, но не варианты шаблонов реализации.

В моих исследованиях и поисках шаблонов Java EE 6 я скорее придерживался подхода Адама Бина, в частности «Постоянных доменных объектов» (PDO)шаблон (в своей книге, но суммированный здесь также: http://download.java.net/general/podcasts/real_world_java_ee_patterns.pdf),, который, по-видимому, предлагает наименьшую сложность и большую синергию с моим текущим приложением POJO. PDO также тесно согласуется с традиционной объектно-ориентированной философией и подходом и действительно обращается кменя.

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

Я также хотел бы знать, есть ли альтернативы шаблону PDO, которые позволяют мне поддерживать структуру приложения (используя полиморфизм и т. д.) без необходимости создаватьсессионный компонент и сущность JPA для каждого класса в моей модели.(Я не хочу делать это отчасти из-за большого объема упражнений, необходимых для рефакторинга всех модульных и интеграционных тестов, а отчасти потому, что, насколько я вижу, я в конечном итоге попытаюсь повторить мои объектные отношения 1toMany и т. Д.через мои сессионные бобы тоже, что кажется сумасшедшим).

Есть ли у кого-нибудь опыт, которым можно поделиться - или если вы хотите отметить, что я идиот и пропустил что-то фундаментальное в Java EE 6, что тоже будет "приветствоваться":)

ТИА

Answer 1

Нет ответов, так что, возможно, я единственный, кто делает это;) Для всех, кто ищет указатели, я нашел:

• ваша объектная модель нуждается в серьезной модификации. Вы не можете использовать Карты или Списки интерфейсов, как в приложении не-JPA, потому что JPA не может «обрабатывать» интерфейсы, вам нужно сохранять (абстрактные) классы. Hibernate имеет аннотации @Any и @ManyToAny, но накладные расходы (производительность, функциональность и кодирование) является (ИМХО) значительным. Если тогда вы можете реализовать отвратительную абстрактную иерархию классов. YUK!

• Если у вас смутно сложная объектная модель (более шести отношений между объектами), вы получите множество команд JOIN в коде SQL, который генерируется механизмом JPA. Я где-то читал, что> 6 JOINS создает большую нагрузку на базу данных (я уверен, что это просто правило). MySQL имеет жесткий предел в 61 соединение. Звучит безумно высоко, неужели ты никогда не попадешь в это ?! Если у вас есть иерархия абстрактных объектов и несколько отношений между объектами, это скоро сложится!

Я не нашел способа обойти первую «проблему». Чувствовать себя нехорошо, добавляя множество абстрактных базовых классов вместо интерфейсов, но, насколько я понимаю, это неизбежно. Пожалуйста, скажите мне, если нет!

Вторая проблема может быть решена с помощью lazy-fetch для отношений объектов или с помощью шаблона шлюза Адама и расширенных сеансов персистентности (вместо загрузки сеансов без сохранения состояния и сохранения модели при каждом вызове). До сих пор я иду с последним, но пока не дошел до того, что смог бы провести нагрузочное тестирование использования памяти и базы данных. Посмотрим!