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

Question

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

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

В моих исследованиях и исследованиях, которые ищут шаблоны Java EE 6, я скорее воспринял подход Адама Бьена, в частности шаблон «Persistent Domain Objects» (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 не может использовать интерфейсы «дескриптор» 10, вам необходимо сохранить (абстрактные) классы. Hibernate имеет аннотацию @Any и @ManyToAny, но накладные расходы (производительность, функциональность и кодирование) значимы (IMHO). Если вы можете реализовать отвратительную иерархию абстрактных классов, то вам следует. YUK!

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

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

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