At 11:24 24.01.00 , you wrote:
sorry for not really answering your question but you asked for pragmatic
answers.
what we do a lot (the idea came from rickard �berg on this list, thanks) is
use lazy loading bean methods by using finder methods, which circumvents
the problem (if there is one), is easy to develop (in fact we generate this
code from an ER model) and looks like this: your PhoneNumberHome has a
finder method like findByPerson and then your PersonBean will have a method
(all exception stuff skipped) like this:
public Collection getPhoneNumbers(){
// ... somehow get phoneNumberHome
return phoneNumberHome.findByPerson(this.id);
}
works great (even with brainddead one-row one-bean mapping techniques), is
extremely simple and not too bad in terms of performance if your app server
is reasonably optimized for entity beans.
our approach to project work (especially in prototyping) is: throw that
stuff (remember, it's all generated code) at your data model, see where you
cannot afford the overhead and redesign those remaining parts using session
beans or BMP. it turns out there's lots of places were we found the
performance of this approach to be good enough, which means lots of time
(and money) saved. of course that might only work well for some classes of
projects but so far I have encountered quite a few of those.
regards,
robert
>Hi
>I have read back and forth about DON'T reference entity beans from another
>entity beans, as well as the opposite. I have failed to get a good logical
>reason why this is bad and obviously is entities referencing each other
>convenient from time to time.
>
>For example: I want to use CMP beacause it's fast to develop and the
>database is very simple. A person has a bunch of phone numbers. If I design
>the person entity bean to have a bunch phone number entities in a vector.
>(The vector IS NOT a CM field). Otherwise I need a session bean (or the
>client, god forbid) to be a proxy for these two entity beans to have some
>useful object to work with.
>Of two bad things, I think the first one is the best.
>
>Are there some transaction, DB-locking issues I haven't thought about here?
>
>
>I am not asking about fine or coarse grained component design here. I'm
>programming to provide a good money/quality ratio for my customers.
>Therefore a pragmatic answer to this would be very appreciated.
>
>Regards
>Erik Romson
>
>===========================================================================
>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".
(-) 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
===========================================================================
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".
