![]() |
|
Модераторы: LSD, AntonSaburov |
![]()
|
|
| Maverick |
|
|||
|
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1307 Регистрация: 22.9.2003 Где: Odessa, Ukraine Репутация: 2 Всего: 10 |
Добрый день... не мог бы кто-нить объяснить....
Вот есть два CMP .... Bean1 и Bean2... Оба CMP... В Bean1 есть CMP-поля int key, String name.... В Bean1 аналогично есть CMP-поля key, name... Создаем хваленную контейнерную взаимосвязь в Bean1 к Bean2... пусть односторонню, пусть один-к-одному.... Скажем в ejb-конструкторе Bean2 будет написано create(1,"test2")... создается прекрасно... Что будет написано в конструкторе Bean1? create(1, "test1", ......... (видимо, указатель на второй бин каким-то образом?)).... Как это организовать? Каким образом? У меня очень много бинов-классов получается, очень трудно эти связи фасадами удерживать... Слишком много кода... Подскажите, пожалуйста, подробно как правильно организовать контейнерную связь между двумя CMP? В последнее время прочел очень много статей, но везде что-то опускается как само собой разумеещееся... |
|||
|
||||
| Maverick |
|
|||
|
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1307 Регистрация: 22.9.2003 Где: Odessa, Ukraine Репутация: 2 Всего: 10 |
Кто-нить вообще юзает EJB 2.0??? Или это глас вопиющего в пустыне??
|
|||
|
||||
| tux |
|
|||
![]() Летатель ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 1853 Регистрация: 10.2.2005 Где: msk.ru Репутация: 74 Всего: 132 |
||||
|
||||
| Maverick |
|
|||
|
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1307 Регистрация: 22.9.2003 Где: Odessa, Ukraine Репутация: 2 Всего: 10 |
Ужас.... что посоветуете? пероползать на EJB3? сильно отличается?
Блин, мы их уже два -три месяца тужимся и мучаем.... Добавлено @ 15:30 Как же все-таки связи организовать правильно?? Пока не разберусь - не переползу ни на что... Добавлено @ 15:31 И вообще... что EJB2.0 4-5 лет назад была??... А какого же тогда Sun до последнего времени их пропагандировала?? |
|||
|
||||
| tux |
|
|||
![]() Летатель ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 1853 Регистрация: 10.2.2005 Где: msk.ru Репутация: 74 Всего: 132 |
||||
|
||||
| Maverick |
|
|||
|
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1307 Регистрация: 22.9.2003 Где: Odessa, Ukraine Репутация: 2 Всего: 10 |
Спасибо... ждем до понедельника...
|
|||
|
||||
| tux |
|
|||
![]() Летатель ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 1853 Регистрация: 10.2.2005 Где: msk.ru Репутация: 74 Всего: 132 |
Должен быть указатель на локальный или удаленный интерфейс. Как это должно быть описано в ejb-jar.xml не нашел. В старых проектах все кроме самой реализации EJB генерируется с помощью XDoclet, настраивать его муторно. Добавлено @ 22:41 Мучались дольше, но тогда спросить было не у кого. Все-таки рекомендовал бы перейти с EJB 2.0 на что-то другое если вам не нужны распределенные транзакции. Альтернатив множество - EJB 3.0, Hibernate, iBatis. |
|||
|
||||
| Maverick |
|
|||
|
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1307 Регистрация: 22.9.2003 Где: Odessa, Ukraine Репутация: 2 Всего: 10 |
Так это все IDE по умолчанию создают локальный, но локальный невозможно создать вне контейнера насколько я понимаю? Как же вызвать такой метод из веб-приложения скажем?? путсть оно на том же сервере крутится?? Или все равно получается надо фасадами обкручивать все, просто фасады чуток проще получаются....
вот так можно получить ссылку на удаленный интерфейс... Bean2Bean");
как же тогда получить на локальный ссылку? в том же фасаде?? Скорее всего именно они и нужны... кластеризация, чудовищные объемы и все такое... спросить тож не у кого... Этот XDoclet есть у меня, и даже JDoclet... пока эту гадость изучишь - уже глова лопнет... А потом еще EJB ковырять... Наверно, надо на третий уходить... огородами... Уйду обрато в Дельфи... |
|||
|
||||
| tux |
|
||||||
![]() Летатель ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 1853 Регистрация: 10.2.2005 Где: msk.ru Репутация: 74 Всего: 132 |
Из веб-приложения, которое в той же JVM крутится без проблем. Если на другом сервере, тогда нужен удаленный. С ним, насколько я понимаю проблем быть не должно, все примерно так же, как и с локальными. Однако, есть одно "но". Удаленно вызывать Entity бины не рекомендуется - изменение каждого атрибута (коих обычно много) потребует сетевого вызова, что по производительности, сам понимаешь, не будет соответствовать никаким требованиям. Поэтому так и поступают, все оборачивают фасадами, используя различные паттерны и кучу дополнительного кода. Так что, альтернативы две - либо приложение, крайне неэффективное по производительности либо монструозное с точки зрения количества вспомогательного кода.
На самом деле там все не так уж сложно. И если уж занялись EJB, то рекомендовал бы изучить, сильно помогает и избавляет от необходимости синхронизировать постоянно состояние бина и десяток интерфейсов и XML-дескрипторов.
Это еще не повод использовать EJB. Вот если есть несколько баз данных на разных серверах, которые между собой связать средствами самих СУБД не получится, тогда да, EJB, и то можно обойтись без них. Есть более легкие средства для обеспечения межбазного взаимодействия. Ну или в конце концов можно на EJB 3.0 переползти. Сам не работал, но народ хвалит.
Вот-вот. Такого рода технологии и приводят к тому, что считается, что Java - это безумно сложно. |
||||||
|
|||||||
| chief39 |
|
||||||
![]() карманная тигра ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 1631 Регистрация: 20.5.2005 Где: Киев Репутация: 11 Всего: 77 |
В двух словах:
Энтити лучше делать локальные, почему - Tux описал. Заворачиваешь в фасады. Методы фасадов должны отвечать сформулированным человеческими словами запросам и действиям. То есть быть более крупнозернистыми. Плюс, на входе/выходе методов фасадов должы быть transfer objects(паттерн). Энтити желательно за пределы фасада не выносить как понятие. И работать в основном с локальными энтити. Если должны взаимодействовать два сервера - пусть взаимодействуют через фасады - так будет скрыта работа с БД и энтити можно будет легко поотм изменить/заменить. Плюс - скорость маленькие куски из рабочего ejb-jar: Бин - Тип Категорий и бин Категория. Связь, весьма очевидно - один ко многим. Думаю, тут всё прозрачно, более конкретные вопросы задавай по мере появления, буит врем- отвечу. На еджиби-кьюэльные запросы пока внимания не обращай, пропусти мимо ушей их. Тип категорий
Категории
Описание релэйшнов, то есть таких себе форейн ки
ЗЫ: Рекомендую поглядеть на еджиби 3.0 Для себя(для понимания) можно попробовать несколько рабочих примеров на 2.0(2.1) но что-то серьёзное - лучше уже на 3.0 Все преимущества 2.1 но гораздо меньше ворох кода. Проектировать новую систему под морально устаревающую технологию не стоит, сан уже вовсю 3.0 пропагирует, короая собрала в себя наработки хибернейта и многих других полезных фреймворков. 2.0 и впрямь тяжеловата в плане количества поддерживаемого кода и его массивности -------------------- Люди - это свечи. Они либо горят, либо их - в жопу!(с) |
||||||
|
|||||||
| Maverick |
|
||||
|
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1307 Регистрация: 22.9.2003 Где: Odessa, Ukraine Репутация: 2 Всего: 10 |
chief39, я все это проделывал много раз... и разметки такие же получаются... и запросы тоже мутил - работают... горы фасадов наработано... но их слишком много - трудно контролировать их уже... потому что связи между cmp я сам поддерживаю...
меня больше интересует код классов и интерфейсов этих двух бинов... если можно их показать - будет великолепно... до меня не доходит - как получить ссылку на локальный интерфейс свзянного бина... что должно быть в ejbAfterPost? вернее, что должно быть, я знаю... а вот как это написать - не понимаю... Добавлено @ 15:21 Например: есть страна
и есть регион
Регион знает свою страну... По уму надо связать компонтенты напрямую и пускай контейнер разбирается, что к чему... Вместо этого я в регионе храню идентификатор страны, а потом в большом фасаде Адрес собираю воедино... Но если учесть, что много бинов - страна, регион, город, тип улицы, почтовые данные и тп и тд - фасад получается монстроидальный... вместо того, чтобы создать регион и успокоится - я создаю и регион и страну, и еще куча проверов всяких... |
||||
|
|||||
| chief39 |
|
||||
![]() карманная тигра ![]() ![]() ![]() Профиль Группа: Участник Клуба Сообщений: 1631 Регистрация: 20.5.2005 Где: Киев Репутация: 11 Всего: 77 |
Гм... эт как? Даже прямым скл в базе нужна страна, а потом регион создавать уже со ссылкой на страну.
Никуда не деться. Если ты всё это перенесёшь в БД и построишь логику на процедурах - они будут такими же. Если ты имеешь в виду: Есть регион(его айди), нужно вытянуть экзепляр бина связанной страны, тогда: findbyprimarykey по регионам - получение бина региона, получение айдишки страны геттером, findbyprimarykey по странам с имеющимся айди страны или Описывается запрос на ejb-ql в котором идёт выборка по двум бинам и возвращается в качестве обжекта бин страны. Тогда это вопрос в кьюэлю, задавай. Референсы - это всего лишь копию форейн ки поверх БД. Для ограничения целостности и подсказки кьюэль запросам кого и по чём можно связать. Или я во что-то недовъехал? Добавлено @ 17:17 Судя по всему, это то о чём я говорил, афтерпост тут не при чём - это работа файндеров, которые ты напишешь -------------------- Люди - это свечи. Они либо горят, либо их - в жопу!(с) |
||||
|
|||||
| Maverick |
|
||||||||
|
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1307 Регистрация: 22.9.2003 Где: Odessa, Ukraine Репутация: 2 Всего: 10 |
Я, видимо, что-то неправильно объясняю...
Расмотрим обычные классы...
Отображаем их в бины .... Country отобразится в бин напрямую поскольку все поля простые... А Region не сможет... Так как поле country сложного типа... Я вообще-то думал, что EJB2 позволит мне отобразить эту связь почеловечески... Во всех статьях указано, что контейнер сам возьмет на себя обязанность отслеживать связанные классы... Вместо этого мне в бине RegionBean приходится держать простое поле idCountry и хранить в нем привязанный идентификатор страны, а потом самому собирать все это... Это ненормально - когда класс не проектируется сам в базу... Добавлено @ 17:55 Вообще-то считал, что будет как-то так
Чтобы контейнер сам понял, что имеется в виду в под countryBean... а счас я делаю так...
Это ненормально... это EJB1 какой-то... |
||||||||
|
|||||||||
| Mikamj |
|
||||||
|
Новичок Профиль Группа: Участник Сообщений: 22 Регистрация: 19.2.2007 Где: Владимир Репутация: 1 Всего: 1 |
В EJB с CMP есть понятие CMR-поля. Это поле должно быть типа локального (и только локального!) компонентного интерфейса другого EntityBean. Допустим мы имеем Entity-компонент Book и Bookcase (книги лежат на книжной полке). При этом в компоненте Book есть ссылка на полку, на которой находится книга. В этом случае методы ejbCreate и ejbPostCreate компонента Book выглядят так:
В фасаде (кстати можно сделать отдельные фасады для каждой сущности, чтобы они гигантских размеров не получались) добавление книги быдет выглядеть следующим образом:
Отображением системы Entity-компонентов на БД происходит с использованием спец. XML-дескриптора. В данном случае связи в базе будут аналогичными. Однако ничто не мешает в Entity-компоненте Bookcase сделать ссылку типа Collection<BookLocalHome>, а потом настроить правильное отображение этой системы на БД. |
||||||
|
|||||||
| Maverick |
|
|||
|
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1307 Регистрация: 22.9.2003 Где: Odessa, Ukraine Репутация: 2 Всего: 10 |
Mikamj, ты просто супер... именно то самое...
последний вопрос "bookcaseHome ищем в методе setEntityContex" - как это сделать?? каким образом?? покажи код, пожалуйста... |
|||
|
||||
![]()
|
| Правила форума "Java" | |
|
|
Если Вам помогли, и атмосфера форума Вам понравилась, то заходите к нам чаще! С уважением, LSD, AntonSaburov, powerOn, tux. |
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | Java EE (J2EE) и Spring | Следующая тема » |
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |