Object Factories with Lazy Loading in C#

[cyberjoe]

I'm looking for a lazy loading solution in c#.

The idea is, to have a kind of object factory, which will be responsible for creating my entity objects.
When a property of such an object is accesed and it is not yet loaded, the factory
(or a magic watcher) will be able to pause the execution flow for a while (maybe that step is not necessary)
load the missing data (don't know how to specify, from where to load that data----maybe via attributes) and
return to the flow.

My entity objects, do not have a possibility to load the missing data by themselves, because they
are only data containers having private members, which are accessible via public properties.
These objects need to be filled with their data from outside, and therefore many lazy loading solutions
won't work here.

Maybe anyone of you knows the solution for my problem?

Thank You in advance!


Greetz!

cyberjoe

 

[mikeblas]

In managed code, you're going to find that lazy loading of the code isn't really possible. If you reference the type, then you've referenced the assembly -- and referncing the assembly brings the whole thing in.

 

[bassman]

My entity objects, do not have a possibility to load the missing data by themselves, because they are only data containers having private members, which are accessible via public properties. These objects need to be filled with their data from outside

Why must the "entity" objects be this way? This seems counter to good OOD, so without knowing more about your situation (context, requirements, etc) I would question this design.

 

[FreiDOg]

Let me see if I'm understanding everything here.
You've got an Entity class (and presumably some classes derived from it) who's sole purpose is to store data and provide accessors to that data.
When your program accesses an Entity who's data has not yet been loaded, for whatever reason, the Entity will ask the object factory to load its data in for it. (Got to agree with bassman, without more info this seems needlessly complicated. An Entity should have the ability to load its own data members)

Anyway, the object factory gets a request to load data into an Entity, presumably the object factory needs some way to picking the correct loader function at runtime (otherwise this would be a pretty simple problem).
Depending on the how the Entities will want data loaded, and what information about that data the Entity will hold, it could just be a lookup table of loader functions in the factory, or maybe use System.Reflection to examine the factory object, or even separate assemblies for appropriate loader functions.
Either way, could you post what an Entity might look like, and what data types it might hold?

 

[carden]

why would this be a bad design? if the data is gathered from a database or something, should the factory not create proxy objects, then once they try and access the data the proxy object loads it? or am I talking out of where the sun dont shine?

 

[bassman]

The reason I'd question it is exactly what FreiDOg said - an object should have the ability to load its own data members. Otherwise the object is tightly coupled to whatever "loader" object is used (in addition to the factory). I won't say it's bad outright; maybe there are additional constraints on the design I don't know about and this is a matter of picking the "least worst" design.

Still, if I was in on this design review, I'd insist on a good reason for it being this way. Often times strange designs like this are not necessary and there's a better way to solve the problem.