Entity beans

[Tim]

I've been reading a lot about EJBs and entity beans and what I've
concluded is that they (entity beans) are basically a means of getting
persistence data to and from the various storage technologies. Perhaps,
they concern themselves with managing relationships between the various
types of information in the various beans.
Is that true and if so, isn't the programming for these beans relatively
redundant, insofar as, once you have determined what to do for one, you
can use the same types of methods and variable definitions on most of
the other ones. I realize there will be different types of entity bean
relationships and so forth but, isn't it pretty similar once you've done
the first few for a specific environment?

 

[Ashton]

I realize there will be different types of entity bean
relationships and so forth but, isn't it pretty similar once you've done
the first few for a specific environment?

Yes.

It took me about three entity beans to realize that xdoclet/ejbdoclet
was a great idea for getting rid of much of the drudgery for individual
beans. Along with a superclass to get rid of repetitive template-style
code, that cleaned up a lot of it.

Things could be improved with an "entity generator" where you customize
bean properties and have the tool write the xdoclet tags. I imagine
some IDEs have this. Oddly, NetBeans has something like it for classes
in general, but lacks the EJB smarts (...or I haven't found the right
templates, perhaps).

 

[Tim]

Yes.

It took me about three entity beans to realize that xdoclet/ejbdoclet
was a great idea for getting rid of much of the drudgery for individual
beans. Along with a superclass to get rid of repetitive template-style
code, that cleaned up a lot of it.

Things could be improved with an "entity generator" where you customize
bean properties and have the tool write the xdoclet tags. I imagine
some IDEs have this. Oddly, NetBeans has something like it for classes
in general, but lacks the EJB smarts (...or I haven't found the right
templates, perhaps).

So if I can change the topic a little to how entity beans are used. If
you look for, as an example, all customers whose customer id starts with
a "5", you will end up with possibly hundreds of entity beans, each with
a different customer id's various related properties.
Is this technically feasible? Isn't it wasteful from a resource
perspective? Aren't you coping into storage all of the methods for each
bean? That's got to take up memory?
Is there some cutoff point at which this technique is no longer
considered feasible?

 

[Sudsy]

I've been reading a lot about EJBs and entity beans and what I've
concluded is that they (entity beans) are basically a means of getting
persistence data to and from the various storage technologies. Perhaps,
they concern themselves with managing relationships between the various
types of information in the various beans.
Is that true and if so, isn't the programming for these beans relatively
redundant, insofar as, once you have determined what to do for one, you
can use the same types of methods and variable definitions on most of
the other ones. I realize there will be different types of entity bean
relationships and so forth but, isn't it pretty similar once you've done
the first few for a specific environment?

Yes. It's just another abstraction layer. You could pull out MySQL and
put in DB/2 and your application wouldn't see any difference. If you
were using stateless session beans with embedded JDBC calls then it
would be a more painful migration.
It would be fairly straightforward to write a script or program which
automagically generated the entity bean code given the definition of
a table or view.

 

[Ashton]

Is this technically feasible? Isn't it wasteful from a resource
perspective? Aren't you coping into storage all of the methods for each
bean? That's got to take up memory?
Is there some cutoff point at which this technique is no longer
considered feasible?

Conceptually, it's not that different from any other form of database
programming. A lot of the performance is controlled by implementation
details. An entity bean is like a record wrapper, but whether that
means in-memory loading of an entire cursor isn't part of the definition
(as far as I know). Within a single thread, methods shouldn't be any
more of a memory problem for 100 instances of a bean than for 1.

My biggest performance complaints have been about CMR and the generation
of seemingly-unnecessary SQL statements...combined with inefficiencies
in workarounds that are necessary to offset some holes in EJB-QL. (I
spent much of yesterday trying to find a good EJB solution to something
that was taking seconds per query. I ended up putting a trigger in the
database that reduced the time to about nothing. I'm not happy with the
database dependency, but reality had a veto.)

If you're using a database where you can turn on statement logging, I
recommend it.