the spec is correct, don't make your EJBs to fine grained, it will cost you
development time and later on you will have to change it anyway.
Only use EJB when you have data that should go under transactional states.
What we do is that one EJB represents data in different data structures
that are regular java objects inside the entity bean.
So for a invoice bean it would be something like this
InvoiceBean
Vendor getVendor()
void setVendor(Vendor data)
Order getOrder()
void setOrder(Order data)
just a simple example - the opposite would be this
InvoiceBean
getInvoiceNumver()
setInvoiceNumber()
getVendorName()
setVendorName()
OrderBean getOrder()
VendorBean getVendor()
Filip Hanik
Engineering Manager/Architect
XMarkstheSpot
[EMAIL PROTECTED]
Come for the cash, stay for the convenience @ http://www.XMarkstheSpot.com
DaveFord
<dford@SMART-SOFT To: [EMAIL PROTECTED]
.COM> cc:
Sent by: A Subject: PhoneNumber and Address as
EJBs?
mailing list for
Enterprise
JavaBeans
development
<EJB-INTEREST@jav
a.sun.com>
03/27/00 07:34 AM
Please respond to
A mailing list
for Enterprise
JavaBeans
development
Would you guys recommend making PhoneNumber and Address classes EJBs? How
about LineItem of an invoice? I was reading Ed Roman's "Mastering
EnterpriseBeans", and he made order line items and EJB. But I recall the
EJB
spec said not to model fine grained, dependent objects as EJBs. What your
opinion?
Dave Ford
===========================================================================
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".
===========================================================================
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".
