 | |
Re: Input needed, using lazy load with business entities
Dotnet Distributed Applications microsoft.public.dotnet.distributed_apps
 |
| | Thread Tools | Search this Thread | Display Modes |
#1
 
| |||
| |||
|
Re: Input needed, using lazy load with business entities -
06-25-2003
, 09:01 AM
|
Hi TEK, I'm having the same problem and the solution I'm thinking about to use is to hand the entity a logic instance (with your words). So the entity will call the logic component instance (via an interface) when it needs data to be lazy loaded. When strictly using Service Layer pattern [Fowler PoEAA], it seems to me that it creates this lazy load-problem... The solution I mention above doesn't feel that very good. I will carefully follow this thread to see if there will come up better proposals. Best Regards, Jimmy www.jnsk.se/weblog/ ### "TEK" <trondeirikkolloen (AT) hotmail (DOT) com> wrote in message news:eU7Qs9uODHA.1072 (AT) TK2MSFTNGP10 (DOT) phx.gbl... Hello I could need some input on this issue. All ideas would us received with thanks... Application structure: - Thin client (currently an windows app) - Business layer Business Entity components Business logic components - Data layer The Business Entity components is created by the Business logic components. typically usage: User user = new User(); UserInfo myself = user.GetUserByName("tek"); // do stuff with myself ;-) user.SaveUser(myself); The Business Entities may also contain other business entities, UserInfo may for example hold an collection of GroupInfo objects. (the groups a user is member of). So to the issue, with large listings (for example when calling user.GetAllUsers()), you may only need/want the basic information, not the connected info objects. Normally, a logical way to solve this would be to implement layze loading, meaning that the users Group would not be filled until the calling method actually called: GroupInfoCollection groups = myself.Groups(); But to do that, the entity layer would have to have a reference to the Business logic components, and wholia, a sircular reference. At the same time that would lead to put business logic into the info objects, which I'm not to keen on. Any good ideas out there? Best reagards, TEK |
#2
| |||
| |||
|
|
I think a key post mentioned here is analyzing the use case and returning a subset of the object graph. Hopefully this can be narrow down to a few (maybe 2 or 3) load varieties and avoid lazy load altogether because its a pain. |
80/20 situation. For 80% of the times, we can avoid lazy load, but for some
situations we do need it. If we try to always avoid lazy load, I think that
we will end up loading too much or having a very large API.
Ice also wrote:
Quote:
|
Fabrizio's method of solving this problem seems to be the cleanest. |
understand Fabrizio correctly, this is exactly how I do it in my
architecture. But Ice knows that I'm not making this up, right?
:-)
Just one note. I will probably not serialize the member that holds the ref
to the BL (Service Layer) instance, because on the consumer-side, I want the
objects (Domain Model objects or Data Transfer Objects) to speak to a
Consumer Helper layer instead. Actually not very important regarding this
discussion.
Best Regards,
Jimmy
###
"Ice" <ice (AT) nospam (DOT) com> wrote
Quote:
|
All - I'm not sure if the service layer enforces this at all. I'm sure you could have your domain model directly call the mappers, but that would nullify the whole reason why the mappers exist. I think a service layer and data transfer object are essential because you don't want the client to be dependent on the domain model (but this is probably opening up another can of worms). I think a key post mentioned here is analyzing the use case and returning a subset of the object graph. Hopefully this can be narrow down to a few (maybe 2 or 3) load varieties and avoid lazy load altogether because its a pain. Fabrizio's method of solving this problem seems to be the cleanest. ice "Jimmy Nilsson" <Jimmy.Nilsson (AT) nospam_jnsk (DOT) se> wrote in message news:eE5TNRvODHA.2316 (AT) TK2MSFTNGP11 (DOT) phx.gbl... Hi TEK, I'm having the same problem and the solution I'm thinking about to use is to hand the entity a logic instance (with your words). So the entity will call the logic component instance (via an interface) when it needs data to be lazy loaded. When strictly using Service Layer pattern [Fowler PoEAA], it seems to me that it creates this lazy load-problem... The solution I mention above doesn't feel that very good. I will carefully follow this thread to see if there will come up better proposals. Best Regards, Jimmy www.jnsk.se/weblog/ ### "TEK" <trondeirikkolloen (AT) hotmail (DOT) com> wrote in message news:eU7Qs9uODHA.1072 (AT) TK2MSFTNGP10 (DOT) phx.gbl... Hello I could need some input on this issue. All ideas would us received with thanks... Application structure: - Thin client (currently an windows app) - Business layer Business Entity components Business logic components - Data layer The Business Entity components is created by the Business logic components. typically usage: User user = new User(); UserInfo myself = user.GetUserByName("tek"); // do stuff with myself ;-) user.SaveUser(myself); The Business Entities may also contain other business entities, UserInfo may for example hold an collection of GroupInfo objects. (the groups a user is member of). So to the issue, with large listings (for example when calling user.GetAllUsers()), you may only need/want the basic information, not the connected info objects. Normally, a logical way to solve this would be to implement layze loading, meaning that the users Group would not be filled until the calling method actually called: GroupInfoCollection groups = myself.Groups(); But to do that, the entity layer would have to have a reference to the Business logic components, and wholia, a sircular reference. At the same time that would lead to put business logic into the info objects, which I'm not to keen on. Any good ideas out there? Best reagards, TEK |
#3
| |||
| |||
|
|
All - I'm not sure if the service layer enforces this at all. I'm sure you could have your domain model directly call the mappers, but that would nullify the whole reason why the mappers exist. I think a service layer and data transfer object are essential because you don't want the client to be dependent on the domain model (but this is probably opening up another can of worms). I think a key post mentioned here is analyzing the use case and returning a subset of the object graph. Hopefully this can be narrow down to a few (maybe 2 or 3) load varieties and avoid lazy load altogether because its a pain. |
How do you imagine this done? Using the same info object, but load it
differently based on the call method, or actually include two set's of info
objects?
Regards, TEK
Quote:
|
Fabrizio's method of solving this problem seems to be the cleanest. ice "Jimmy Nilsson" <Jimmy.Nilsson (AT) nospam_jnsk (DOT) se> wrote in message news:eE5TNRvODHA.2316 (AT) TK2MSFTNGP11 (DOT) phx.gbl... Hi TEK, I'm having the same problem and the solution I'm thinking about to use is to hand the entity a logic instance (with your words). So the entity will call the logic component instance (via an interface) when it needs data to be lazy loaded. When strictly using Service Layer pattern [Fowler PoEAA], it seems to me that it creates this lazy load-problem... The solution I mention above doesn't feel that very good. I will carefully follow this thread to see if there will come up better proposals. Best Regards, Jimmy www.jnsk.se/weblog/ ### "TEK" <trondeirikkolloen (AT) hotmail (DOT) com> wrote in message news:eU7Qs9uODHA.1072 (AT) TK2MSFTNGP10 (DOT) phx.gbl... Hello I could need some input on this issue. All ideas would us received with thanks... Application structure: - Thin client (currently an windows app) - Business layer Business Entity components Business logic components - Data layer The Business Entity components is created by the Business logic components. typically usage: User user = new User(); UserInfo myself = user.GetUserByName("tek"); // do stuff with myself ;-) user.SaveUser(myself); The Business Entities may also contain other business entities, UserInfo may for example hold an collection of GroupInfo objects. (the groups a user is member of). So to the issue, with large listings (for example when calling user.GetAllUsers()), you may only need/want the basic information, not the connected info objects. Normally, a logical way to solve this would be to implement layze loading, meaning that the users Group would not be filled until the calling method actually called: GroupInfoCollection groups = myself.Groups(); But to do that, the entity layer would have to have a reference to the Business logic components, and wholia, a sircular reference. At the same time that would lead to put business logic into the info objects, which I'm not to keen on. Any good ideas out there? Best reagards, TEK |
|
« Previous Thread
|
Next Thread »
| Thread Tools | Search this Thread |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.