The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Lazy loading via events?

What do you think about implementing lazy loading for an object via events?  For instance, if you have an object with a large image field, you could have the event:

public event EventHandler NeedsImageLoaded;

A controller that knows where the data for the field is stored registers to listen.  Then the public getter for the field would fire off the event if it was hooked up and the actual private value would be loaded.

Of course there are more generic ways to accomplish such events, NeedsPropertyLoadedEventHandler, perhaps.
John Cromartie Send private email
Friday, August 31, 2007
 
 
Gut reaction: it seems overengineered. Why can't the getter directly call whatever it is that loads the value?

Or, to phrase it differently, what problem does your proposal solve that a more conventional lazy loading scheme does not?
clcr
Friday, August 31, 2007
 
 
The idea is to separate the model classes from the data access classes.  Unless it would be a good idea for a model to know how to save itself... which couldn't hurt, right?  Currently there are classes devoted to saving and loading business objects.

There are probably some other design areas that need to be addressed...
John Cromartie Send private email
Friday, August 31, 2007
 
 
"Unless it would be a good idea for a model to know how to save itself... which couldn't hurt, right?"

Why not? What's the disadvantage of having the model call the appropriate methods on the loading/saving classes directly?

The issue I see with your proposed design is that the source code to the model classes gives no clue as to where the data comes from or how it's loaded. One has to have a much more comprehensive knowledge of the system in order to understand such basic things.

I think that what you're suggesting would make the code considerably harder to understand. What concrete benefit do you gain that outweighs that?
clcr
Friday, August 31, 2007
 
 
That's an excellent point about knowing where the data comes from.  The lazy-load-via-event idea did work, but I am going to just let my model classes handle saving and loading.  It's simple serialization after all.  The question that remains in my mind is how do the models know *where* to save?  I guess I'll just Do The Simplest Thing That Could Possibly Work for now.
John Cromartie Send private email
Friday, August 31, 2007
 
 
Follow the 80/20 rule on this one.  Write a simple class that saves the model for you.  Right now, just have it serialize the  classes as you're currently doing.

It's worth wrapping that code in another class to keep that stuff outside of your model.
Lally Singh Send private email
Saturday, September 01, 2007
 
 
"Why not? What's the disadvantage of having the model call the appropriate methods on the loading/saving classes directly?"

Coupling. Unless you use an interface for the dependency, the model can never be persisted to any other source.

If you use an interface you have a factory problem: you first need an instance of a serializer that implements the interface.

There is an intrinsic problem (paradox) with serializing private state of an object model without the model having knowledge of the serializer. You have to choose which one is the lesser evil: implementing serialization specific support on your object model (an external serializer can use to extract/inject private data) or have a dependency between model and serializer (interface).
Marc Jacobi Send private email
Monday, September 03, 2007
 
 
Dont use events for this: you would need threads, and multi-threaded code, which gets you into unnecessary trouble.

If you want to separate "spatial information" (where is the data store), use helper classes, interfaces, configuration files, connection strings.

You should use events, threads and multi-threading if you have to manage some "time information" (when do I have to load it?)....
But this is a rare case.

Always avoid events and threads, unless really needed.
Johncharles Send private email
Monday, September 17, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz