I have done something very similar for these types of objects, sometimes
known as "control tables" or "well known objects". Rather than an entity
bean, though, I use a stateless session bean on the server, with a singleton
hierarchy on the client that acts as a facade to the session bean and also
caches the objects on the client once they are retrieved. I implement a
common abstract superclass, with concrete subclasses for each type of object
(one for states, one for countries, etc.) The superclass does most of the
work, but delegates some behavior to the concrete subclasses using the
template method pattern. Additionally, the subclasses provide type safety.
The trade off is that clients will not get changes to these collections
until the user signs off and back on, but this is usually acceptable for
these types of objects.
--Chip
> -----Original Message-----
> From: Murali Krishna Devarakonda [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, August 16, 1999 9:08 PM
> To: [EMAIL PROTECTED]
> Subject: Singleton, Bean-managed Entity Bean, to lookup (mostly)
> Read-only tables
>
> Hi,
> Will someone be kind enough to blow my idea to bits?
> Or tell me that it does make sense:~)
>
> I have several read-only tables such as:
> A. "States", "Countries", "ZipCodes", etc.
> B. "genres", "moods", etc.
> ... and so on.
>
> They are all Read-only for the most part. While modification of a)
> is more rare than that of b), it's conceivable.
> I have entity beans represented by a table in the database that
> have
> foreign keys pointing to tables
> in A., like "User"
> in B., like "Song"
>
> A form will need to provide the values from the Read-only tables
> as
> drop-down lists.
>
> The information in tables in A. and B., is frequently accessed,
> shared by several "clients", and may(although very rare) need to be
> modified.
> So, I'm thinking I can have a ROTables Entity Bean(for want of a
> better name:~), that's a singleton(created with a predetermined
> primary-key(say, int pk=0, and not allow any other primary key), and that
> supports methods like:
> getStates
> getCountries
> getZipCodes
> getGenres
> getMoods
>
> etc.
>
> Are there any problems in this design? Is there a Better way to do
> this?
>
> Thanks for your input.
>
> Regards,
> Murali Krishna Devarakonda
>
> ==========================================================================
> =
> 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".
