Hi!,
As somebody proposed their solution for supporting inheritance in finder
methods, i have the following view point regarding EBeans.
1. It should be possible for a deployer to use third party ebeans and
compose a new entity out of them. This means in the deployment descriptor
we should have a compositor where we can add the constituents. The
constituents can refer to e-beans. This will give us leverage in changing
the granularity depending on the deployer. If I have a thrid party
CustomerOrder bean,under some context this may have fine granularity, and
we may prefer Customer entity instead.
For example if there is a compositor ebean super1 composed of
ebean1 and ebean2(third party) .super1 can be a logical entity or
physical, in the latter case the relationship between super1 and its
constituents reflect the underlying schema.
Depending on whether they are Logical or Physical, their lifecycle may
be different.
Now we can query the super1 by either ebean1 identity or ebean2
which should return us instance of super1.
Following describes lifecycle for super1:
- When we say create super1 and pass required values for its
constituents, it delegates to the respective finder methods to see if
they exist, if not delegate to their create methods instead. The
result of this step is a new ebean which has references to third
party ebeans.
- For find methods, we can have choice of finding by its different
constituents or by the identity of super1(if it exists in dbms).
findByebean1();
findByebean2();
findByebean12();findyby both
When i say query super1 how are you going to query an Object?
By delegation.
If i say findByebean1(), what container is going to do is delegate
this find call to ebean1 finder method and if it exists give us this
super1 instance with ebean1 as one of its constituents.
Now what happens when you say find by both ebean1 and ebean2, it
will again delegate to both ebean1 and ebean2 finders and check for
returned objects if both of them are not null.If not null, give us
super1 ref with ebean1 and ebean2 as their constituents.
Now it is POSSIBLE that this super1 may exist in dbms in which case
super1 will reflect the underlying schema relationship with its
constituents.
It is POSSIBLE that super1 is a logical object that deployer needs
to compose of, in that case container can maintain a pool of this
instances and change its constituents dynamically.(MAYBE this is
dynamically aggregation)
- When we say remove, container will execute remove recursively on
constituents and compositor. Here comes referential integrity.
I think composition than inheritance can give ejb programmer lots of
leverage and better reusability .
Any comments or disagreement welcome?
Punit
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
===========================================================================
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".
