Hi Ruben
Yes we do have corresponding persistence classes. So the Address entity has
a corresponding AddressPS class. At its simplest (and our default) this maps
1:1 to the DB-entity, but it doesnt have to. Yes you should always access
EJB entities via a Session Bean (this is for imo a business logic reason -
you shouldn't let clients have "raw" access to your entities.) Should you
use EJB entities at all ? Well our (my project's) opinion is: nope. We don't
use them at all (but then our code has to run outside of the appserver
environment as well - so our requirements are a bit err unusual). As far as
I can tell the only things we lose are: a deployment descriptor with the EJB
entities (for defining reference data) - obviously no EJB bean equals no
deployment descriptor. The only other suspicion we have is that the app
server may cache EJB entities, but that doesn't appear to be a big deal from
the performance testing we are doing.
As it happens our entities are a little more complex than that as we also
have PS classes to handle each complex relationship (including the shared
instance example you gave) that also implement demand loading.
So given your example:
Customer -->* Address *<-- Employer
You would have the following classes:
Customer }
Address } This is what the outside world sees
Employer }
CustomerAddressProxyList } Implements demand loading of a Customer's
addresses, uses the CustomerAddressPS and AddressPS classes
EmployerAddressProxyList } Implements demand loading of an Employer's
addresses, uses the CustomerAddressPS and AddressPS classes
CustomerPS } Maps Customer onto the database, (interface)
AddressPS } Maps Address onto the database, (interface)
EmployerPS } Maps Employer onto the database, (interface)
CustomerAddressPS } Maps the Customer --> Address relationship onto the DB,
(interface)
EmployerAddressPS } Maps the Employer --> Address relationship onto the DB,
(interface)
Note that the two proxy lists could use the SAME implementation of AddressPS
(so they could map to the same DB table and therefore be shared) or they
could use DIFFERENT implementations of AddressPS.
Most of the functionality of the ProxyList classes is actually implemented
in an abstract base class. Most of the effort in all this goes into the PS
classes.
Edward
-----Original Message-----
From: Bakker Ruben [mailto:[EMAIL PROTECTED]]
Sent: 11 December 2000 10:20
To: 'jBoss'
Subject: AW: [jBoss-User] jBoss: Can it cope with many bean classes?
Hi Edward,
Thank you for this detailed and helpful answer.
Some more questions:
You've got 100 db-entities, but only 8 entity beans. These components seem
to be rather powerful and access many db entities at once. Do you have a
persistence layer or classes that are not EJBs "behind" the EJBs? Do these
correspond to the db-entities? Should we create entity beans at all? Many
people advise not to access entity beans directly, but through session
beans. What is the value of entity beans then...
How do you cope with some classes used in different contexts? Say you have
an address and the address class can be used in the context of a customer or
in context of an employer or as a supplier. If I understand you right,
address isn't a EJB and its located somewhere behind the scene...
Ruben
-----Urspr�ngliche Nachricht-----
Von: Kenworthy, Edward [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 7. Dezember 2000 09:39
An: 'jBoss'
Betreff: RE: [jBoss-User] jBoss: Can it cope with many bean classes?
If you have 400 different entity beans then it sounds like your entity beans
are far too fine-grained (similarly for your session beans).
[To give you a for instance, the system I am currently working on has of the
order of 100 entities, but only 8 EJB entity beans. It has around 40 session
beans (session bean corresponds to use case in our system, and I am of the
Ivar Jacobson, *BIG*, ie proper, Use Case school - so 40 use case system is
roughly an 40 man-year project, and multi-million pound).]
The problem you will have is that to do anything realistic with a
fine-grained system (eg 400 entities) will require the instantiation of many
EJB entities and that is expensive in terms of both system resources and the
app server having to manage all these teeny EJB entities. It migh be worth
reviewing your design and seeing if you can cluster your entities together.
Eg you may have Customer -->(many)Order --> (many)Product. Is Order really
separate from Customer ? Probably not, you probaly only rarely (if ever)
deal with it separately from Customer so perhaps Order (entity) and Customer
(entity) should be combined into a single EJB entity.
The mistake people often seem to make is mapping classes 1:1 to EJBs. EJBs
are *components*. The mapping, particularly for EJB entities, I would expect
to be many classes in one EJB.
A simple rule of thumb to find you EJB entities that we've used is: what's
the relationship ? association or aggregation, if the latter then you're
probably looking at two classes in one EJB entity (doubly so if its a
containment aggregation.) That of course is a technical way of saying look
at the life-times and context. Is one ever used (instantiated) without the
other ?
Hope this helps :-) But probably not in the way you had hoped.
Edward
PS
Oh and for all but the simplest systems, CMP is completely inadequate. it
leads to you defining hundreds of tiny EJB entities that will perform like a
dog :-) Use BMP.
-----Original Message-----
From: Bakker Ruben [mailto:[EMAIL PROTECTED]]
Sent: 07 December 2000 07:43
To: '[EMAIL PROTECTED]'
Subject: [jBoss-User] jBoss: Can it cope with many bean classes?
Hello everybody.
We've building a large ERP-System and like are planing a transition from a
custom CORBA App-Server to EJB. We currently have about 400 different
EntityBeans and about 200 SessionBeans most of them stateful. Can jBoss cope
with this? Is EJB in general designed for such large applications? Has
anybody experience in building large applications with EJB (jBoss?)?
Any answer is very much appreciated...
Ruben
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
