Под J2EE есть море паттернов, но с приходом Java EE 5 они банально устарели. Интернет наводнен инфой по паттернам J2EE. Не подскажете, где можно найти хорошую информацию по паттернам под JEE5? 

Особенно интересуют следующие: 
1. Session Facade 
2. Message Facade 
3. Service Activator 
4. EJB Command 
5. Service Locator / Lookup Utility 
6. DTO (Data Transfer Object) 
7. Data Transfer Hash Map 
8. Value List Handler 
9. Data Transfer Row Set 
10. Data Access Object 
11. Data Access Command Bean 
12. Entity Version Number 
13. Primary Key Generation 
Но, другие тоже будут интересны  

 Еще раз подчеркну, что эти паттерны есть и под J2EE - вот, к примеру, http://java.sun.com/blueprints/corej2eepat...erns/index.html НО ПАТТЕРНЫ НУЖНЫ ИСКЛЮЧИТЕЛЬНО ПОД JAVA EE5

На русском сайте сана есть pdf-ки по паттернам. Может тебе подойдет.

Igor28, ведь в твоем вопросе уже был ответ   

http://ru.sun.com/java/j2ee/index.html

  



это аккордеон уже.

Я конечно извиняюсь.
Но у меня возник тоже такой вопрос. И ответ на него я не на sun-ом сайте, не в гугле, не по приведеным выше ссылкам найти не смог.
Конкретно меня интересует Data Transfer Object, Transfer Object.

http://ru.wikipedia.org/wiki/DTO



Собствено о чем идет речь? И как быть с этим в EJB 3.0?

Примеры из туториала я смотрел

И мне например не очень нравиться такая реализация:

javaeetutorial5/examples/ejb/order/order-ejb/src/java/order/request/Request.java



Хотелось бы увидеть в параметрах DTO. Вобщем что-то более красивое и соответсвующее патернам под j2ee.

P.S. Возможно я чего-то непонимаю?

Я вот такие вещи свожу к Entity, которые у меня и бродят от слоя данных, по слою бизнес-логики до представления и назад.
Собственно даже параметры реквестов сводятся к объектам модели.
Для простого примера. Извиняюсь, что в теме о паттернах не использую стандартное решение AAS.
1. Есть форма логина, у нее два поля user.login, user.password
2. Принимает реквест определенный контроллер таким методом



потом вызывается метод login, который делегирует вызов в SessionFacade через его метод


тот в свою очередь или делегирует вызов USerManager или напрямую зовет UserDAO.
А те уже через JPA делают стандартный запрос логина в базу

Может это имелось в виду?
А вообще и в EJB3 можно применять паттерн DTO. Иногда заказчики заказывают такое, что бы модель от представления была жестко разделена слоем DTO.
Я этот принцип применяю, если мне надо из бизнес-слоя вернуть несколько разных сущностей.

В последнем проекте применил принцип из SOA - Message. Этот объект имеет head & body. В head содержится инфо о том, какую бизнес-операцию выполнять, а body содержит объекты, над которыми нужно выполнить эту бизнес-операцию, а также содержит объект результата этой бизнес-операции.

А на самом деле в EJB3 можно использовать многие описанные тобой паттерны. Все дело в фантазии, опыте и выставляемых требований

Т.е. ты используешь EJB Entity в качестве Transfer Object?

А как решается проблема связи многие-ко-многим при lazy стратегии?

Мне не нравиться идея создавать еще один Transfer Object я хочу использовать EJB Entity в этом качестве.
Я считаю что создание еще одного слоя  Transfer Object помимо EJB Entity только раздует проект и усложнит.

А можно ли клиенту через бизнес методы отдавать  EJB Entity (3.0)? Какие могут быть последствия?

Приходиться вызывать бизнес-метод, менеждыть перзистом сущность и явно вызывать на нем гэтер lazy-коллекции



А в чем собственно проблема? именно так и делаю. Имею jar с пакетом сущностей, который и ложу в CLASSPATH клиента. Все сущности implements Serializable
И вуаля!! Усе работает. Они EJB Entity (3.0) только в том случае, если лежат в jar, который помечен как ejb. Во всех остальных случаях это POJO, И никто не запрещает тебе вызывать на нем new Entity 

Возможные последствия:
1. Потеря производительности
В текущем пользовательском контексте на клиенте как правило не нужны все данные содержащиеся в Entity. Тем ни менее они подгружаются из базы (при этом ejbql транслируется в кашу неоптимальных join'ов), инстанциируются в объекты, сериализируются, передаются на клиента, десериализируются -- со всем вытекающими. Для бизнес методов возвращающих списки сложных объектов с глубокой вложенностью падение производительности может стать критическим.
2. Брешь в безопасности
Классы Enities отдаваемые клиенту содержат по сути структуру базы данных, имена полей, таблиц, а иногда и код запросов (если используются NamedQueries).
3. Смешение слоев
К примеру, обращение к lazy полю Entity на клиенте даст ClassNotFoundException, поскольку у оторванного от контекста объекта (deattached) будет вызван запроксированный метод который должен подгружать данные "по запросу" используя функциональость orm фреймвока (например, hibernate), которого на клиенте, само собой, нет. А подключать к клиенту, который понятия не имеет о базе данных, пакеты hibernate -- такой же моветон, как явно ловить ClassNotFoundException при вызове getter'а.

Если ущерб от перечисленных проблем существеннее, чем необходимость разрабытывать быстро, то решением может быть использование Data Transfer Objects.

Добавлено @ 14:25

Согласен. Лепить еще кучу однотипных классов на сервере и клиенте -- неприятно (хотя иногда разумнее, чем тащить все через Entities -- почему, написал выше).
Приходилось участвовать в реализации решения, при котором DTO (на клиенте и на сервере) изготовлялись специальной фабрикой налету, с использованием функциональости java.lang.reflect (в частности Proxy). И никаких лишних классов.


Это сообщение отредактировал(а) Maksym - 10.6.2009, 14:26

Спасибо за разъяснения.
Видимо все-таки без DTO ни как. Как-то разработчики Sun не продумали эти моменты.
Слишком много классов получается.



А можно об этом по подробней? Или это закрытая информация?

Да я, вобщем то, весь смысл уже написал. Посмотри как сделать прокси (в ссылке которую я дал). На базе любого Entity можно создать прокси с такой же сигнатурой и наполнить данными из этого Entity  (данные можно хранить внутри прокси в виде HashMap<имя метода, данные> и возвращать в хендлере). Можно делать этот прокси на базе интерфейса, содержащего сабсет Entity (только то что нужно клиенту в данном контексте). Сделай пару прокси, погоняй и сразу прийдут идеи как использовать.