One approach is to only have one Entity Bean, Fund Detail, and provide a
service layer that returns the various views required by clients. This
facade layer allows you to assign difference security requirements for the
different views.
So a client never sees Fund Detail of Fund directly, but rather interacts
with FundServices which is a session bean providing the various views.
-Chris.
> -----Original Message-----
> From: James Cook [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, August 13, 1999 10:46 AM
> To: [EMAIL PROTECTED]
> Subject: Summary Beans?
>
> I'm attempting to convert an RMI Factory based program to EJB.
>
> I have a table (FUND_DETAIL) of data that looks like this:
>
> ID YEAR APPAMT OBLAMT DESCRIPTION
> === ==== ====== ====== ===========
> 315 1997 20 20 Secret Fund
> 315 1998 15 8 Secret Fund
> 315 1999 8 0 Secret Fund
> 220 1998 15 15 Special Fund
> 220 1998 10 6 Special Fund
>
> Each row in this table represents an object called FundDetail, and I have
> implemented this as an EJB. It seems to fit all of the criteria and it has
> a
> significant number of business methods associated with it.
>
> The interesting twist is I have need for another object that represents a
> Fund at a higher level. This object is identical to the FundDetail class
> without the presence of a year. Most of the amounts are summed. The data
> for
> this object (Fund) would look like. I don't really have a table for this
> object, this is just for clarification:
>
> ID APPAMT OBLAMT DESCRIPTION
> === ====== ====== ===========
> 315 43 28 Secret Fund
> 220 25 21 Special Fund
>
> I have thought of various designs for this relationship, and I would like
> to
> pick the collective brain (ouch) of this newsgroup for EJB-friendly
> representations.
>
> Here are some of the thought processes I have considered.
>
> Fund as an Entity Bean
> ======================
> This didn't seem prudent as the Fund object doesn't represent a row in a
> database. Furthermore, a user will create a new Fund by creating a new
> FundDetail (with a year). If Fund was an entity with it's own database
> table, I would have to enforce referential integrity in my FundDetail's
> ejbCreate and ejbRemove methods which seems, at the very least, a great
> performance drag. Is there a way for Fund to be an Entity without its own
> database table?
>
> Fund as a Stateless Session Bean
> ================================
> This is the way I am leaning right now. The user would request the AppAmt
> for a Fund, and a database query would result in the correct summary
> information. It just seems kludgy to me, since the table is not normalized
> at the fund level, and a change to description would result in a multiple
> row update.
>
> Fund as an Entity, FundDetail as a dependent
> =============================================
> A little more radical. I would be responsible for syncing the FundDetail
> object. I could still use the FundDetail table, and CMP would be out of
> the
> question.
>
> I'd be interested in other options as well. What do you think?
>
> jim
>
> ==========================================================================
> =
> 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".
