To many fortunate DBAs, the phrases ‘lazy loading’, ‘lazy initialization’, ‘deferred loading’, ‘on-demand loading’ ‘indirection’ and ‘just-in-time loading’ have no power to evoke distress or loathing.  For the rest of us who are more involved in application development, these dread words are alternative labels for  a system common to all Object/Relational Mappers (ORMs), in which the ORM can opt to delay the retrieval of properties of a non-scalar  ‘object’ from the database until you request them in code. This device can provide better performance if used properly, but such is the cozy cocoon provided by an ORM that the programmer is only vaguely aware of the consequences down the line from an innocent access of a property such as the ‘Order details’ of a customer order.  It is very easy to unwittingly cause huge amounts of  slow,  and unnecessary, work at the database layer, especially when the mere access of the value of the property can lead to a return trip to the database.

ORMs can be very valuable, but cause problems when used badly. There are several ways of avoiding ‘Lazy-Loading Lethargy’. Many problems happen when programmers use properties, which imply merely retrieving an existing  field value, rather than a method, which implies the likelihood of consequential work.  It also helps to ‘profile’ applications carefully when developing them in order to detect this sort of problem. Better still, you can sidestep all these problems by taking care in the design of the Data-Access Layer (DAL).  ORMs are growing up. Whereas Hibernate was originally  entirely innocent the existence or use of stored procedures or functions and mapped only onto views and base tables, now the Entity Framework (v4) allows the database developer to have complete control over the logical interface between the database and the Data Access layer. It can make a huge difference to performance as well as the obvious benefits to security and the ease of refactoring.

If you are conscious of the nature of the database entities, and their relationships, you are less likely to produce an application that thrashes the database. ORMs like to promise an alternative consequence-free access to a database’s base tables. In reality, what can work with AdventureWorks merely brings a real commercial database to its knees.  You can’t blame the ORMs or even ‘Lazy Loading’: the mistakes usually happen from the misuse of perfectly good development aids. Developers now have better tools, but they still need the skills to use them properly.