Not sure I like the idea of using inheritance hierarchies to implement
views. If there are lots of views the inheritance hierarchy will be quickly
crowded. IMHO, in good design practice implementation inheritance should be
relegated to providing default implementations of common behaior in based
classes as in you a&b below.
-chris
> -----Original Message-----
> From: James Cook [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, August 18, 1999 9:06 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Inheritance and EJB
>
> Encapsulating data as a tier in an EJB component model is probably the
> stickiest problem with EJB. You bring up a good point.
>
> Just for basic object serialization needs, the design should work, but I
> haven't seen any containers that will allow you to persist an attribute of
> an attibute. For example, if all of your data to be persisted is wrapped
> in
> a MyBeanData object, it would be nice if the container allowed the CMP
> field
> to be specified as myBeanData.name.
>
> The issue of views could be handled with further inheritence within this
> data object. It would depend on the situation. I am successfully using all
> of the other tiers with my beans to provide some benefits to my
> development
> process:
>
> a) There is no persistence code mixed in with my business logic. All
> access
> for ejbLoad, ejbStore, etc. is abstracted into its own layer.
>
> b) My reusable superclass contains useful code for generating unique ids
> (EJB based, see previous posts regarding UUID bean), attribute history
> (useful for assisting BMP and tuned updates), null implementation for all
> ejb methods (prevents me from having to constantly supply empty
> ejbActivate() methods, ejb context handler (no more setEJBContext()
> implementations), and optional debug methods for printing "now in
> ejbPassivate()".
>
> I haven't been able to encapsulate my data in an object yet, unless I'm
> sure
> that I am using BMP. Then, I can do what I want. I haven't run across a
> situation where views are necessary, but I see your point.
>
> jim
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Raber
> Sent: Wednesday, August 18, 1999 4:37 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Inheritance and EJB
>
>
> James,
>
> This is interesting, but is it always the case that you want all of the
> serialized state of sampleData returned to the client?
>
> Think of an Employee bean, where some clients are allowed to see salary,
> and
> some are not...
>
> Because of this sort of scenarion, we advocate a view object be used to
> return to different clients only what those clients need or are allowed to
> see.
>
> -Chris.
>
> > -----Original Message-----
> > From: James Cook [SMTP:[EMAIL PROTECTED]]
> > Sent: Wednesday, August 18, 1999 11:24 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Inheritance and EJB
> >
> > Since this topic is garnering some attention now, I though I'd post a
> > prior
> > message regarding the topic. I apologise for the redundancy.
> >
> > Original Post
> > ==============
> > I've thought of doing something like this, but backed off because I
> wasn't
> > sure how an EJBServer would support container managed persistence (CMP)
> > with
> > this approach. This topic is also an extension to the list-thread:
> > "generic
> > EJB thoughts"
> >
> > I finally came up with a hierarchy that seems to work well, although I
> > haven't tested it yet. Set your email viewer to non-proportional fonts
> and
> > the diagram below will make much more sense (It's hard to draw UML with
> > ASCII:
> >
> > +--------------+ implements +----------------+
> > | EntityBean | <- - - - - - - - | BaseEntityBean |
> > +--------------+ +----------------+
> > | ejbLoad(){} |
> > | ejbStore(){} |
> > +--------------+ +----------------+
> > | Sample | <-------+ ^
> > +--------------+ +------------+ | extends
> > | |
> > +--------------+ contains +--------------------------+
> > | SampleData | <--------------- | SampleBeanLogic |
> > +--------------+ +--------------------------+
> > | | SampleData data |
> > | implements +--------------------------+
> > V | SampleData getData() |
> > +--------------+ | void setData(SampleData) |
> > | Serializable | +--------------------------+
> > +--------------+ ^
> > ^ | extends
> > | implements |
> > | +---------------+
> > +--------------+ | SampleBean |
> > | SamplePK | +---------------+
> > +--------------+ | ejbCreate(id) |
> > | ejbLoad() |
> > | etc... |
> > +---------------+
> >
> > BaseEntityBean: responsible for a null implementation of EntityBean
> > interface. I actually have code in this class that can optionally
> printout
> > the time and method that is executing. That gives me some ability to
> view
> > when the container calls my ejbLoad, ejbStore, etc. methods. Also
> > setEntityContext and unsetEntityContext are implemented here.
> >
> > Sample: remote interface that declares the business methods available.
> >
> > SampleBeanLogic: only an implementation of the Remote interface goes in
> > here. This looks very good as there is no EJB specific code, only
> business
> > logic. There is also an attribute of type, SampleData which is a
> reference
> > to the object holding the business attributes. I implement the setData
> and
> > getData methods that pass the business attributes with a high level of
> > granularity. This satisfies the purpose that started these threads and
> > countless other threads on granularity.
> >
> > SampleData: a class that contains business attributes. Under certain
> > circumstances, when a Java client is involved, these classes could
> contain
> > field-level validation methods if the EJB server supports pass-by-value.
> > This simple validation will be very useful on the GUI client, and should
> > save much network traffic.
> >
> > SampleBean: for CMP beans, this is where the implementation of ejbCreate
> > will go, and that's about it. For BMP, all of the appropriate
> persistence
> > methods are implemented. This is very good separation since only
> database
> > code will exist here in most circumstances.
> >
> > SamplePK: hasn't changed.
> >
> > I would also advocate the business/remote separation pattern that has
> been
> > kicked around here. It creates yet another class, but for die-hard (aka
> > Glutteous Clenchimus) OOPists you can separate the Sample class into
> > SampleBusiness that is extended by Sample (which extends EJBObject). The
> > SampleBeanLogic then could implement SampleBusiness to ensure that the
> > appropriate classes were implemented at compile time.
> >
> > Could this be the holy grail of EJB design? Hardly, but it's worth
> > investigating. There have been other posts that mention a name-value
> pair
> > or
> > hashtable approach to passing data to and from the client. I suppose
> > name-value pairs as long as they were stored in an array to achieve
> > maximum
> > language/platform independence. XML would work as well. Personally, I
> > think
> > the SampleData class should perform better, require much less coding,
> and
> > in
> > the Java-Java world it should allow some validation to take place on the
> > client.
> >
> > The first problem that comes to mind with this approach involves CMP.
> With
> > the data attributes hidden behind an object reference (sampleData), how
> > could these Containers know which fields to persist? For those using
> > OODBMS,
> > I suppose you would persist the sampleData object...problem solved. For
> > the
> > other 80%(?) of us, I think we're stuck, until the Containers get just a
> > tiny fraction of a hair smarter and allow us to specify persistent
> > attributes as "sampleData.firstName".
> >
> > Secondly, I know some containers that can't even handle the
> > business/remote
> > separation pattern I mentioned earlier, let alone handle the separation
> of
> > the EntityBean implementation described above.
> >
> > I'm not sure if these shortcomings are our fault. I think we should be
> > able
> > to change our EJB component design to suit us, as long as it adheres to
> > the
> > spec. I think the container vendors should look upon this pattern as a
> > feature request. Some vendors may be able to support the pattern now. If
> > this is the case, I would look forward to hearing about it. If not, what
> > are
> > the challenges in implementing such a design?
> >
> > Now if we could convice Jim, Ian, the Valto folks or others to put up
> some
> > concrete diagrams describing the ever ellusive "EntityBean as
> Collections"
> > and the "Definitive Guide to What is a Dependent Object, and How Does
> One
> > Use Them?" all of life's mysteries would be solved. Then we could start
> > coding some applications for a change ;-)
> >
> > 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".
>
> ==========================================================================
> =
> 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".
