I'm probably flogging a dead horse, but I wanted to pipe in with a me too here.
Using EJBs as facades for our object graphs has been our approach all along. I suppose
this is what happens in a relational world trying to limp into an object oriented one.
Unfortunately, we've found problems with this.
1. Bean managed persistence was really our only choice. (though I've been told
toplink was an option at one point).
2. Some of our sub-objects are Entity beans in their own right. Our approach so far
is to give facades to these sub objects in certain places. This will be an issue when
sharing starts to take place.
3. Caching. Having these complex objects built by complex sql queries begs the
question of caching. This is an area that EJB is sorely lacking.
4. Locking causes us a lot of grief as well, when we have to understand how the
sharing in 2 and whatever caching we can think of in 3 will affect our designs.
To be bold, I'd like to say that EJB is the beginning of a useable object oriented
database for business applications. The relational model was great, but it only
handled state, while EJB brings behavior into the mix. Unfortunately, it is fairly
obvious that the spec is still in its infancy ..
On Fri, 15 Jan 1999 09:03:34 -0600, Chip Wilson <[EMAIL PROTECTED]> wrote:
>see below
>
>> That may depend on the application type. One part of our application
>> (at the moment fat-client arch.) consists of an asset analysis of our
>> customers. We have a graph like this (simplified):
>>
>> Customer
>> - Asset
>> - Asset
>> - ...
>> - Liability
>> - Liability
>> - ...
>>
>> One type of assets is a surety of another person, potentially a customer
>> too.
>> So this graph can become quite complex.
> [Chip Wilson]
> Consider using coarse grained entity beans to represent sections of
>the instance graph. The instances that you wish to traverse may then be
>requested from the coarse grained bean, which will result in them being
>serialized and sent to the client for "traversal." Changes to the graph can
>similarly be serialized and sent back to the coarse grained entity in the
>context of a transaction for updates.
>
> In your example, you probably need a coarse grained entity called
>Customer, which can be found based on various criteria. This customer
>entity is referred to by proxy, but when you want to traverse the part of
>the instance graph pertaining to assets, you ask the Customer entity for
>that section of the graph and work with it on the client.
>
>> The ability to traverse this graph is essential for our application. If
>> EJB
>> is unsuitable to support this ability, that would be a reason for us to
>> choose
>> another technology.
> [Chip Wilson]
> I see no reason why EJB cannot meet your needs. I look at entity
>beans as facades into the domain layer of my application. Each facade has
>an associated graph of domain instances to which it (the facade) provides an
>interface. Similarly, session beans are facades into the application model
>layer.
>
> The corresponding instance graphs for multiple entity bean instances
>must be disjoint, even if they represent the same persistent objects. This
>will require work to handle concurrent access to the same persistent objects
>from multiple entity beans.
>
> ==========================================================================
>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".
