Database Entity Manager Concept
Hello Forte-Users,
currently I work with the Concept of the White-Paper:
Forte Database Integration Patterns
Forte Consulting
May 1996
to integrate Database-Access into my Warehouse-Application.
Because the hole Application is delivered step by step and we are new
in using Forte, I use for the first step only the patterns described for
the DBEntityMgr to get a "feeling".
The problem is, that if I use the DBEntityMgr-Concept and have many
BaseClasses to access I have a lot of interface-calls like
GetCustomer,GetProducts,etc..
The Database Session Router will also not solve this "problem" in future,
because the
ApplicationEntityMgr has than the same problem.
Question: Know anyone a way, based on the upon described facilities to use
this strategy with a solution to make more "EntityMgrSO's" to get a smaller
DBEntityMgr-Interface?
The Database Session Router is planed for using when the Application should
be used from more Users and when running the SO's on a WorkGroup-Server.
Question: Know anyone a way there to split the ApplicationEntityMgr?
Every reply is welcome.
Thanks forward to all
Joseph Mirwald
Bachmeier & Sporrer
GERMANY
EMAIL: BuPEDV@compuserve.com
Don't worry, which bug you wanna have today?
[1402 byte] By [
] at [2007-11-25 5:01:07]
Joeseph,
The concept of the entity manager having less interfaces is both good and
bad. The good part is mostly related to development - splitting up the
calls to the various SQL managers among several entity managers allows more
flexibility in terms of which classes have to be checked out of the
repository to add to or update the interfaces.
The bad part is that now, the "client" of the entity manager must know
*which* entity manger to call for any particular set of data. This negates
a significant part of the advantage of using the single interface into the
persistence layer.
I've used both strategies in the past, and I tend to stay with one entity
manager with a large number of interfaces. It moves the responsibility of
knowing where to get the data from the client to the service, where it
usually belongs. The only real time penalty is when you compile the
partition - there will be more to compile. But since they are just
interafaces, it shouldn't be that big of a deal.
Don
At 10:49 AM 11/28/97 -0500, Joseph Mirwald wrote:
>Hello Forte-Users,
>
>currently I work with the Concept of the White-Paper:
>Forte Database Integration Patterns
>Forte Consulting
>May 1996
>
>to integrate Database-Access into my Warehouse-Application.
>
>Because the hole Application is delivered step by step and we are new
>in using Forte, I use for the first step only the patterns described for
>the DBEntityMgr to get a "feeling".
>
>The problem is, that if I use the DBEntityMgr-Concept and have many
>BaseClasses to access I have a lot of interface-calls like
>GetCustomer,GetProducts,etc..
>
>The Database Session Router will also not solve this "problem" in future,
>because the
>ApplicationEntityMgr has than the same problem.
>
>Question: Know anyone a way, based on the upon described facilities to use
>this strategy with a solution to make more "EntityMgrSO's" to get a smaller
>
>DBEntityMgr-Interface?
>
>The Database Session Router is planed for using when the Application should
>be used from more Users and when running the SO's on a WorkGroup-Server.
>
>Question: Know anyone a way there to split the ApplicationEntityMgr?
>
>Every reply is welcome.
>
>Thanks forward to all
>
>Joseph Mirwald
>
>Bachmeier & Sporrer
>
>GERMANY
>
>EMAIL: BuPEDV@compuserve.com
>
>Don't worry, which bug you wanna have today?
>
>
============================================
Don Nelson
Regional Consulting Manager - Rocky Mountain Region
Forte Software, Inc.
Denver, CO
Corporate voice mail: 510-986-3810
aka: dnelson@forte.com
============================================
"The good thing about drawing a tiger is that it automatically makes your
picture fine art." - Hobbes
at 2007-6-29 9:20:17 >
...snip
>> The bad part is that now, the "client" of the entity manager
must know
>> *which* entity manger to call for any particular set of
data. This negates
>> a significant part of the advantage of using the single
interface into the
>> persistence layer.
snip ...
[KUBASADA Manjunatha] We can avoid this problem by having the
EntityMgrSO method determine which entity manager to use. The client can
pass a parameter indicating which object to get. The client call would
look like,
myobject = EntityMgrSO.GetEntity(myobjectindicator);
OR
EnitytMgrSO.GetEntity(output myobj : object);
In the second case, the GetEntity method uses the run time type
of myobj to determine which entity manager to call. In both cases the
EntityMgrSO returns an object of type Object; the client would have to
cast it to the appropriate type.
Don, are there any downsides to this approach ?
Manjunatha Kubasada
Complete Business Solutions Inc.
email : mkubasad@cbsinc.com
Ph: (248) 488-2088 X 3480
> --Original Message--
> From: Don Nelson [SMTP:dnelson@forte.com]
> Sent: Saturday, November 29, 1997 4:05 PM
> To:Joseph Mirwald
> Cc:forte-users
> Subject:Re: Database Entity Manager Concept
>
> Joeseph,
>
> The concept of the entity manager having less interfaces is both good
> and
> bad. The good part is mostly related to development - splitting up
> the
> calls to the various SQL managers among several entity managers allows
> more
> flexibility in terms of which classes have to be checked out of the
> repository to add to or update the interfaces.
>
>> The bad part is that now, the "client" of the entity manager
must know
>> *which* entity manger to call for any particular set of
data. This negates
>> a significant part of the advantage of using the single
interface into the
>> persistence layer.
> I've used both strategies in the past, and I tend to stay with one
> entity
> manager with a large number of interfaces. It moves the
> responsibility of
> knowing where to get the data from the client to the service, where it
> usually belongs. The only real time penalty is when you compile the
> partition - there will be more to compile. But since they are just
> interafaces, it shouldn't be that big of a deal.
>
> Don
>
> At 10:49 AM 11/28/97 -0500, Joseph Mirwald wrote:
> >Hello Forte-Users,
> >
> >currently I work with the Concept of the White-Paper:
> >Forte Database Integration Patterns
> >Forte Consulting
> >May 1996
> >
> >to integrate Database-Access into my Warehouse-Application.
> >
> >Because the hole Application is delivered step by step and we are new
> >in using Forte, I use for the first step only the patterns described
> for
> >the DBEntityMgr to get a "feeling".
> >
> >The problem is, that if I use the DBEntityMgr-Concept and have many
> >BaseClasses to access I have a lot of interface-calls like
> >GetCustomer,GetProducts,etc..
> >
> >The Database Session Router will also not solve this "problem" in
> future,
> >because the
> >ApplicationEntityMgr has than the same problem.
> >
> >Question: Know anyone a way, based on the upon described facilities
> to use
> >this strategy with a solution to make more "EntityMgrSO's" to get a
> smaller
> >
> >DBEntityMgr-Interface?
> >
> >The Database Session Router is planed for using when the Application
> should
> >be used from more Users and when running the SO's on a
> WorkGroup-Server.
> >
> >Question: Know anyone a way there to split the ApplicationEntityMgr?
> >
> >Every reply is welcome.
> >
> >Thanks forward to all
> >
> >Joseph Mirwald
> >
> >Bachmeier & Sporrer
> >
> >GERMANY
> >
> >EMAIL: BuPEDV@compuserve.com
> >
> >Don't worry, which bug you wanna have today?
> >
> >
>
>
> ============================================
> Don Nelson
> Regional Consulting Manager - Rocky Mountain Region
> Forte Software, Inc.
> Denver, CO
> Corporate voice mail: 510-986-3810
>
> aka: dnelson@forte.com
> ============================================
>
> "The good thing about drawing a tiger is that it automatically makes
> your
> picture fine art." - Hobbes
at 2007-6-29 9:20:17 >
