"Bhattacharyya, Ana" wrote:
>
> Hi john
> I am new to EJB and am groping for some patterns to design my system using
> entity & session beans. Can u explain what u meant by domain objects??
I can explain what I understand by domain objects as they were explained
to me when I was first coming up to speed, much as you are now. OK, I'm
not John, but this is an issue that's near and dear to my heart. :-)
The conventional wisdom seems to be something like this:
"Entity beans are fairly heavyweight. Therefore you should try to
reduce their numbers. One way of reducing their numbers is to look at
your original design, and try to see where you can group several of your
classes/objects so that they are governed or implemented somehow by a
single entity bean. That way, where in your design you have n objects,
you'll only have 1 entity bean that manages them. Here's an example.
Think of an Order. An Order has OrderItems. But it would be poor
practice [so the theory goes] to make OrderItem an entity bean since it
can be grouped and wholly managed by the Order object. So make Order an
entity bean, and OrderItem one of its dependent objects."
In the above example, OrderItem and Order in your initial design (that
has nothing to do with EJB--you ARE designing without regard to your
implementation technology on your first pass, yes?) are domain objects.
The challenge becomes: how do I map domain objects into EJB? In the
above example, you would make Order an entity bean, and OrderItem a
serializable plain-Java object.
(Now, my opinion.)
In practice--in any kind of system that's more complicated than a simple
web store or a school library or something along those lines--it is not
very common at all to run across dependent objects (i.e. objects that
are wholly owned by one class). Typically if your design is good there
aren't very many wholly contained objects at all, in fact.
The common counterexamples given to this point of view are OrderItem
(which may be the only valid one I've seen) and Address. OrderItem is
only not shared among orders in a simple, standalone purchase order
case. You can easily conceive of other ordering systems that require
both Order and OrderItem to be shared (we're working on a couple right
now--they're common in digital marketplaces). And Address is shared the
minute you start talking about common address books (as in customer
relationship management applications). Products have product
descriptions, but those are often shared, and so on and so on and so on.
So in practice although the pattern is a nice one, I've found that it
rarely fits any moderately complicated system that you're trying to
design. Maybe it's just me.
My theory of the week :-) is to worry about numbers of entity beans only
when I'm doing queries or read-only type accesses--i.e. only when it's
clear that if I don't I'm going to kill my app server. Otherwise, I'm
going to trust in my application server to scale well--the EJB
specification has enough hooks and warts in it to handle high-scale
applications that I'm going to use the features that are there.
Obviously anytime I run across a dependent object (haven't found one
yet) I'm going to use it. And finally full inheritance (of the kind
that you probably see in your domain model) is difficult (but not
impossible) to implement in EJB 1.1.
Lastly, most interaction with the entity bean layer is done (usually)
with session beans anyway, so you're always free to make implementation
changes behind that wall.
I'd be curious to hear others' opinions.
Cheers,
Laird
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
