Let’s say you build an app that uses a traditional ORM concept of lazy loading. Your app binds an Order object to a grid and lets the user lazily load related objects like OrderLines. Your user – a normal cubicle dweller, queries for an Order and then decides to go get some coffee. She comes back, navigates to OrderLines and …
Oops! Some data changed in between the time the Order was explicitly queries and the OrderLines were implicitly lazily loaded. Of course, the ORM builders know and understand the semantics – maybe the app developer (ORM user) also gets it. But how about the app user?
OK. So I have to admit I am not a fan of lazy loading – by any name – deferred loading, demand loading, just-in-time loading, blah loading. For me, it is all about including what you want and then shutting off the darned spigot that brings in the objects. No more lazy stuff coming in from who knows what state and who knows in what amounts!
All users are welcome to follow this way. Otherwise, lazy ORM users deserve “it”. But what is “it”?
– Exposure to concurrent changes in the database. So you can get a frankengraph instead of a regular object graph.
– The abomination of getting all the objects that were ever stored in the database but were afraid to load if you weren’t doing lazy loading. How about ten years worth of orders for a given Customer instead of getting the two Orders from last week?
OK. So the purists say – you get your complete object – any piece of code that I pass my Customer object to knows that it can see the full set of Orders – only one dangerous navigation away. Think of it like nice little landmines. Ouch, that one blew a couple of megs!! Arrgh – that one ruined consistency of my data.
What about you? Are you wandering in a minefield 😉
If not, we have just the right thing for you. More about it in the next instalment.