Идеологический вопрос по работе с EJB объектами

Привет Всем!

Вот не могу решиться, как поступить в данной ситуации - что вы думаете?

СИТУАЦИЯ:
Есть модель, котрую нужно воплотить в жизнь(т.е. в программу :-)). Речь идёт о некоторой части программы 'склад'. Точнее часть, которая отвечает за номенклатуру товара. Т.е. весь список товара, его описания, категории и, собственно, наверное всё.
Модель вырисовывается такая:
• ProdItem - объект отвечающий за единицу товара (сюда описание не входит, оно вынесенно в отдельный объект)
• ProdCat - объет отвечающий за одну категорию - т.к. товар, по задумке, может входить в несколько категорий, то это ещё можно назвать ключевыми словами, но, к тому же, задумывается ещё и наследуемость категорий.
• ProdCatToProdItemLink - объект, отвечающий за связь между категориями и товаром(один товар может входить в несколько категорий).
• ProdItemDescription - объект, который хранит описание для какого-то товара. Я ещё не решил, что здесь может быть, может какая-то HTML'ка, может картинка... в общем что-то...
• ProdItemToProdItemDescriptionLink - соответственно связь между товаром и его описанием.
Конечно, для всего этого дела предусмотрен фасад, который будет работать с одноимёнными, но простыми типами данных. Это для того, чтобы не было потерь производительности из-за бешенного количества сетевых циклов. Т.е. фасад будет выдавать клиенту объект типа mypackage.data.ProdItem, который будет содержать все те же поля, что mypackage.ejb.ProdItem. Т.е. смысл думаю понятен.
Кстати персистенцию я думаю использовать исключительно BMP.

А ТЕПЕРЬ, СОБСТВЕННО, САМО СОМНЕНИЕ:
Если будет использоваться фасад, нужно ли вообще делать Entity Beans для каждого из объектов?
Если делать, то: Каждый объект будет заниматься своей персистенцией самостоятельно. И загрузка N объектов повлечёт за собой минимум N операций SELECT.
Если не делать, то: Фасад можно, например, сделать Stateful и, чтобы он как-то кешировал объекты для пущей производительности. Но, самое главное это то, что за один SELECT можно сразу загрузить нужное количество объектов.

ЧТО Я ДУМАЮ:
Я сколняюсь к первому варианту. Т.к. всё-таки, нужно следовать объектной модели. И, конечно, главный вопрос - это как быть с загрузкой множества таких Entity Bean объектов.

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

В общем надеюсь на ваши подсказки.

0

Esli ne ispolzovat ochered to EJB budut rabotat kak udalenni object. Princip marionetki. To est na kliente est stub v kotorom est takije methodi kak na servere a na servere est nastojahij klas. Kogda vi vizivaete method na kliente on visivaetsa na servere i tam rabotaet, zatem peredaet otvet na klient. Vrema zaderjki eto vremja peredachi parametrov na server + vremja raboti servera + vremja peredachi otveta. dla komunikacij ispolzuetsa IIOP protocol. On ja dumau doljen bit bistree HTTP. No ja ne znau tochno.

0

Еще маленькая вводная (как в армии):

как я понимаю (может ошибаюсь?), EJB это отображение БД в апп. контэйнере, т.е. это по сути дела копия БД?
Могу допустить, что контейнер может иметь несколко образов (доменов) и все они между собой отслеживают состояние копий БД.
А если в это время какой-нибудь локальный юзер с клиент-серверного интерфейса вводит то что ему надо в эту самую БД.
Как там EJB контейнер? Он контролирует ситуацию?
Вопрос к тому, что я сейчас ввяжусь в это дело, а окажется, что эта вся фигня годится только для заурядного интенет магазина?

0

Nikak ne otslejivaet. Pered kajdim ispolsovanijem mojno delat update bean. To est on perechitivaetsa. Rejim eststevenno medlenni. Tak chto luche tak ne delat. No s drugoi storoni claster to toje vobshemto nezavisim. Esli odin server v claster obnovil bazu to drugoi to ne znaet. Odin tolko newasns. A chto esli bean nachal transaciu a drugoja etot je bean udalil. To est udalil zapis v baze kotoraja sootvetstovovala etomu bean. Chto bi uznat chto budet pochitaete documentaciju k EJB container. Naprimer k Websphere. Tam eto ochen horosho opisano. I esho sorry no mne kajetsa vi esho ne ochen ponimaete raznicu mejdu Entity i Session beans. Ili termninologiu ispolzueete nepravilno, Sorry, Mojet ja ne prav. No esli tak ne polenites prolistat documentaciju

0