At 22:23 05.11.00 , you wrote:
>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).
check the archive of ejb-interest. bottom line is that the server can cache
or prefetch data from resultsets that bmp doesn't allow. bmp typically
results in many db accesses for finders (retrieving pks and subsequent
ejbloads) where a good cmp engine just uses a few.
>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.
it is not an either-or decision. mix them as you like (typically simple
stuff cmp, complex stuff sometimes BMP sometimes jdbc wrapped with a
session bean). you don't decide to use either a hammer or a drill to build
a house ;-).
>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.
same approach we use and we're quite happy with that too.
>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
regards,
robert
(-) Robert Krüger
(-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH
(-) Brüder-Knauß-Str. 79 - 64285 Darmstadt,
(-) Tel: 06151 665401, Fax: 06151 665373
(-) [EMAIL PROTECTED], www.signal7.de
