Где стоит применять Entity Bean?

Ситуация - имеем 5 таблиц, одна из которых находится в центре идущих к ней связей от других таблиц. Для каждой таблицы создан Entity bean. Цель - получить клиенту массив data обьектов, которые являются слепками модели. Необходимо, чтобы в этом data обьекте были отражены все поля центрального entity обьекта (включая первичный ключ), а также чтобы в этом обьекте находились data обьекты зависимых entity обьектов. В принципе, для зависимых data обьектов достаточно отразить два поля - первичный ключ и название, но это не принципиально. - реализуем шаблон 'Составное представление' (пользуясь терминологией книги 'Core J2EE patterns').
Ну так вот,
1) этот массив обьектов можно создать в помощью одного запроса к базе, обработать результат в цикле и отправить клиенту.
2) Если попытаться реализовать это с помощью Entity обьектов, нам тогда придется создавать каждый зависимый обьект, и брать у него значение первичного ключа и остальных нужных полей.

Вторая реализация конечно пишется быстро, выглядит красиво, абстрактно, первая же будет работать быстрее и меньше загружать сервер (наверное).
И вот мой первый вопрос - может нагрузка во втором случае будет не такой уж большой, и лучше использовать entity обьекты?
И второй вопрос - если здесь не стоит применять entity, тогда где стоит применять?

П.С. сейчас у меня реализовано как описано в первом случае. Пока entity обьекты создал ради интереса. Приколько все таки, когда оно обьектами а не запросами =)

Пока у меня есть такая мысля - что для получения списков следует использовать запросы, а для выполнения каких нибудь манипуляций с данными можно попробовать использовать entity. ( обращение к ним через фасад, а клиент обращается к серверу через Бизнес-делегата)

Вообще этот вопрос самый насущный по EJB, больше у меня таких стопоров не возникало. Пишу на WSAD 5.0 под WebSphere 5.0

0

Net ja phanat Hibernat-e, potom JDO i tolko potom EJB2.0+CMP.

No my point is pered tem kak Xait' chto-n., nado znat' chut' bol'she chem odny tehnologiu.
Est' poslovitsa na etot schet - 'If the ONLY tool you know is a hummer, then everything else looks like a nail'. Na russkom ekvivalenta ne znaju.

0

Посмотрел я Hibernate - вот это правильная документация, там по человечески показано как работа с базой идет, не то что в спецификации EJB, которая получается все это дело оставляет на усмотрение производителя сервера.

0

Hibernate это сила. А то эти фасады с Data Object'ами задолбали меня, хоть и работал с ними по минимуму. И тормозит у меня entity, видно оперативки мало и проц слабоват, WebSpher'e много надо.
Вот я и думал - зачем мне entity bean когда требуется действий по минимум совсем - чтение и изменение базы без особых наворотов (в моем случае).

0

Вот именно. ЕБины придуманы как выделенный слой обработки данных в навороченных системах. До определенного уровня действительно Hibernate или аналогичного средства работы с БД вполне достаточно. Я при разработке Веб-приложений добавляю еще создание и кэширование объектов типа сессий (Session Facades) и объектов-исполнителей (Executors), каждый из которых содержит методы работы с определенным объектом или группой объектов БД - и все летает.

0

Да что ты емы рассказываешь? Если 83 это год его рождения, то у парня опыт работы месяцев 6. Он то весь мир видел только из окна папиной квартиры.

0

Максим Рагозин, тебя послать или сам пойдешь? А, ты же уже там........
А опыта работы у меня полтора года. Но с другими технологиями.

0

И именно от тех технологий у меня остался рефлекс против лишних запросов к базе.

0

Когда у нас работа с базой становится слабым звеном в маштабировании, тогда уже плевать на всю абстракцию и последние технологии.

0

Да, и еще я фанат Oracle'a
PL/SQL forever

0