Есть ли альтернатива bmp?

Господа есть ли возможность использовать CMP компоненты для oc4j или orion, при условии что все обращения к СУБД возможны только через хранимые процедуры (прямые insert и update запрещены).

0

Видно, с подобной задачей никто не сталкивался.
Просто написание bmp, даже используя XDoclet, занимает много времени. Интересно было бы узнать как решаются подобные проблемы в других серверах приложений.

0

Можно решить очень просто - не использовать entity c bmp вовсе. Просто реализуете работу с базными процедурами. И используете эту функциональность в session фасадах.
А реализовывать полностью модель базы при помощи entity beans c bmp - нонсенс - если эта модель достается так задорого - то нафиг она нужна такая ? В базе данных уже есть одна. -)

0

прежде всего необходимо предположить нагрузку сайта или софта.если нагрузка не очень велика то смысла использовать EJB нет вообще обходитесь CollableStatement для процедур и все дела.Если же предполагается большая нагрузка то тогда прийдется обращаться к EJB.Кстати СМР можно написать и в ноутпаде.....)))

Спасибо что откликнулись.
Однако какая мне разница, что буду использовать jdbc через session или через еntity. Большой сложности писать самих bmp используя xdoclet нет. Много мороки писать Statments. Вот этого то, я и хотел избежать, желая использовать cmp, но к сожалению специальных средств изменения персистенции по умолчанию у oriona кажется нет.

0

2 Cayman

По поводу CMP - честно скажу - не слыхал ничего про орион - но использовать не на Weblogic,Websphere, SunOne или JBoss модель EJB CMP 2.0 я бы не рискнул.

> Однако какая мне разница, что буду использовать jdbc через session или через еntity.

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

2 Mishgun
>Если же предполагается большая нагрузка то тогда прийдется обращаться к EJB

Что это Вы имеете ввиду ? Надеюсь не то что EJB увеличивают performance ? С моей точки зрения , EJB полезны тем что предоставляют сервисы на аспектно ориентированном уровне.
Речь прежде всего веду о декларативных транзакциях - и я бы еще 10 раз подумал прежде чем взялся написать свой Transaction Manager.

0

Стандартные опции CRUD нет возможности использовать. Зато есть процедуры их аналоги new([?]),change([?]),delete([?]). Все таки я использую bmp в чистом виде и очень удобно получается со связями между бинами и соответственно использование паттерна Transfer Object Assembler. А насчет готовой модели в виде оракл процедур - все таки эта же модель не объектная поэтому то и приходиться создавать свою объектную модель которую намного удобнее использовать при создании клиента. Ведь даже оракл и борланд придумали нечто похожее BC4J и DataExpress соответственно. Поэтому не вижу смысла отказываться от Entity .

0

Возможно Вы правы. Все зависит от того насколько хранимые процедуры укладываюися в рамки стандартных операций CRUD. В проектах , в которых я принимал участие в последнее время , все операции с базой (включая различные выборки) были основаны на процедурах. При этом и параметры и возвражаемые значения представляли некоторые срезы данных - и они не укладывались в модель entity. Поэтому мы абстрагировались от модели базы и решили общатся на языке DTO(Data Transfer Object) объектов ассоциированных с конкретной операцией. В отличие от концептуальных объектов - объектов , которые обладают всей информацией, котрая МОЖЕТ БЫТЬ ИМ ПРИСУЩА (например entity beans), DTO объекты обладают только информацией, которая НЕОХОДИМА ИМ в данном конкретном месте. В вашем случае ,использование TrasferObjectAssembler также испоьзует этот подход -- входные и выходные параметры являются объектами DTO. При этом требуется дополнительные преобразования в entity и обратно.
Резюме: Нечеткое соответствие (или вовсе несоответствие) даныых участвующих в операциях с базой привело к отказу от entity beans в принципе.

0

to vl_romanov
Я как раз это и имел ввиду.
Если предполагается большое кол-во транзакций(просто немного не так выразился) то без EJB тут не обойтись а если наоборот то можно спокойно обходиться одним jdbc, просто согласитесь что с EJB мороки больше чем с jdbc.Правда года три назад работал я с Intershop-вским серваком так вот только на нем никакого геморроя нету.Даже упаковывать и деплоить их не надо да и писать тоже.Только компиллировать)))

Господа. А как вы смотрите на следующий вид извращения.

(Запрещаем персистентцию по умолчанию для CMP2.0)
А в функциях СMP ejbLoad, ejbCreate, ejbRemove делать обращение к базе данных для выполнения CRUD операций?

теперь объясняю к чему это. Для таблицами , оракловой БД с которой я работаю очень просто и быстро создавать CMP. При этом пакеты оракла также однозначно соответствуют методам бинов. Вызовы делать достаточно просто с помощью sqlj.

Так вот нигде в литературе я не встречал запрета обращать к БД из функций cmp ejbLoad, ejbCreate, ejbRemove. Везде только нерекомендуют.

0

Именно эти методы и надо имплементировать при Bean managed persistence
тк они собственно и являются операциями CRUD.

0