My personal trade off was:
Why not CMP 2.0 style:
- Too scared to use it for real as it is not even officially there ...
Why choose for CMP 1.1?
- CMP is more portable (across db's).
- Working already towards EJB2.0.
- The claim is CMP can be optimized better (I would be happy to know more details
about that, until that time it is a bit
of a bet on a blackhorse for me).
Why choose for BMP?
- I do not know yet whether I'll run into trouble with complex and highly flexible
queries requirements
for Query By Example forms. The requirement for extra flexibility could become an
argument.
I would say if you can spend the time learning enough about CMP 1.1 I would go for
that as a first option. The EJB1.1
specs are even written so that you can sub class a CMP bean to create a BMP bean.
One of the biggest disadavantages of EJB's is the tremendous amount of redundant code
you have to write. Add for
instance a field to a bean. You'll have to change three files minimum and don't make
mistakes as that will cost you time.
This disadavantage applies to both CMP and BMP and will apply to EJB2.0 as well.
What I'm doing is using EJB1.1 CMP and generate beans and stuff using a slightly more
advanced bean
generator then the standard ones. Based on a datamodel (Entity-Relation) it generates
a set of beans for
your application (including the remote and home interfaces and the *.xml files of
course). The generated
beans include the fields, the finder queries, the additional methods to retrieve
related beans etc.
As an additional bonus the beans include a more abstract way to access the properties
(myBean.getProperty(int index))
as the client side of orion does not allow reflection. I use that to generate forms
and tables on the client.
The generator adds a tremendous flexibility (I can switch to BMP / EJB2.0 easily),
makes CMP 1.1 managable and
keeps me away from EJB2.0 while it is still too early for me. For the rest: Im a
notoruios mifftyper and am able to
spend tons of time debug typos in 2638 lines of very closely resembling code. That
problem is solved as well :-)
Frank
On Saturday, November 04, 2000 12:10 AM, Cory Adams [SMTP:[EMAIL PROTECTED]]
wrote:
> At 11:44 PM 11/3/00 +0100, Robert Krueger wrote:
> >At 11:23 03.11.00 , you wrote:
> >>I have looked through the 2.0 spec and find the chapters regarding CMP to
> >>be daunting. It appears as though the complexity of writing my own SQL in
> >>BMP has to be balanced against learning an entire new way of managin
> >>persistence within the XML deployment descriptors which seems to be no less
> >>or perhaps even more complicated than BMP????
> >>
> >>Or am I missing something with regard to CMP being easier?
> >
> >yes, two things:
> >
> >1. your code including the queries is guaranteed to be portable between ejb
> >servers and databases (that's the theory)
> >2. you cannot possibly make optimizations using BMP that the container can
> >make using CMP
> >
> >why do you have to use ejb2.0 CMP? you didn't mention 1.1 cmp as an
> >alternative?
> >
>
> Hmmm..... I can find even less regarding 1.1 CMP. I have the ORielly book
> as well as the Mastering EJB books. The 2.0 spec is what I'm using because
> I would think (perhaps wrongly) that EJB 2.0 would maybe be easier and or
> offer more functionality??? Chapters 9 and 10 are over 100 pages which
> have to do with CMP. The last thing I need to do is learn another query
> language which is what some of the 2.0 spec seemed to indicate I would need
> to do....
>
> I also understand points 1 and 2 above but they do not address my original
> question of the relative complexity between BMP and CMP. Basically 1 and 2
> are irrelevant to me if I can not implement CMP and can not practically
> compare the relative complexity between the two because I just don't
> understand CMP so I will keep digging through examples and utilize the post
> that has been helpful that somebody posted earlier today :
> http://www.execpc.com/~gopalan/java/entity.html .
>
> Thanks,
>
> Cory
>
>
> >regards,
> >
> >robert
> >
> >>Thanks,
> >>
> >>Cory
> >
> >(-) Robert Kruger
> >(-) SIGNAL 7 Gesellschaft fur Informationstechnologie mbH
> >(-) Bruder-Knau?-Str. 79 - 64285 Darmstadt,
> >(-) Tel: 06151 665401, Fax: 06151 665373
> >(-) [EMAIL PROTECTED], www.signal7.de
> >
> >
> >
>
