I am an advocate of the approach you describe. This is
the sort of thing we have had to do with CORBA and other
distributed object environments in order to get them to
perform. Lots of fine grained getters/setters of the wire
will kill you...
Your session bean wrapper (I like to call these Facade's)
can provide a method to return a flattened representation
of your customer bean:
CustView getCustView(CustKey custKey);
It can also provide a corresponding method to update the
customer from the flattened view object. e.g.:
void updateCust(CustKey, CustView custView);
Whether you wrap with session beans or not, you need a way
to pass chunks off data to clients by value. Your entity beans
could also provide methods for flattending themselves to the client.
Whether this responsibility should be in the entity bean, or in
a corresponding session bean is open to debate.
The question of how to handle the flattened representation deserves
some attention. Some alternatives are:
- Define "view" classes that contain only those instance variables
need for a particular view.
- Use key/value pairs (hashtables) to pass the data to/from the client
- Use XML to create a tag based presentation of the underlying data
objects.
XML is perhaps the most flexible, and the most overhead.
Tools that generate the views from the bean object models and "view
meta information" are needed to make the development process
efficient. I expect some opporuntism from the vendors will eventually
fill this need.
Regards,
-Chris.
----------------------------------------------------------------------
Chris Raber, Systems Engineer, GemStone Systems Inc.
100 West Big Beaver, Suite 200, Troy, MI 48084
phone: (248)-680-6691, fax: (248)-680-6689,
email: [EMAIL PROTECTED]
web: http://www.gemstone.com/
----------------------------------------------------------------------
> -----Original Message-----
> From: Francois Staes [SMTP:[EMAIL PROTECTED]]
> Sent: Sunday, February 21, 1999 2:20 PM
> To: [EMAIL PROTECTED]
> Subject: Question regarding Session and Entity Beans
>
>
> Hello,
>
> I'm rather new to EJB technology, so I might be asking stupid
> questions....
>
> I'm having a number of conceptual questions regarding the relationship
> between Entity Beans and Sessions
> Beans.
>
> To facilitate the discussion, I'll try to focus on one example
> throughout the message: suppose one has to implement
> a customer care system where client applications will be used to
> manipulate customer information (e.g. name, address,
> phone number, etc.).
>
> Obviously, we would like to implement the Customer class as an entity
> bean (preferably using some kind of container
> managed persistency). This Customer bean than would have a number of
> accessor methods to get/set the various customer
> attributes.
>
> It's clear that it is not feasible to expose these methods to client
> applications as this would require many calls to be made from the
> client application to the EJB server to retrieve a customer's name,
> address, etc..
>
> Hence, it is proposed quite often to use a session bean to hide the
> entity bean to the client application. The client application then talks
>
> to the session bean, and the session bean talks to the entity bean.
>
> Although I understand the advantages of this approach quite clearly
> (especially when having clients that only need to access some of
> the attributes of the entity bean, and as a logical place for
> implementing business logic rules), I don't see very well how it solves
> the
> communication problem mentioned above. One could allow the client
> application to retrieve customer information from the session bean
> in two ways:
>
> - Implement a large number of methods in the session bean to retrieve a
> specified customer's name, address, etc.
> (and having the same excessive communication problem as explained
> before);
>
> - Implement one (or a few) methods in the session bean, and have these
> methods work in a CustomerData object (something that
> holds information on a customer and that can be sent to the client
> application and back using serialization).
>
> When implementing the second solution there obviously is a strong
> relationship between this CustomerData object and the original
> entity bean.
>
> So, I'm wondering whether I'm the only one with these thoughts, and
> whether any tools have been defined to generate this kind of
> CustomerData objects from a given entity bean.
>
> Anyone willing to share some thoughts on this ?
>
> Thanks,
>
> Francois Staes
> << File: Card for Francois Staes >>
===========================================================================
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".
