A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
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.
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?
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...
"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?
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.
"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).
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.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz