Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

ORM Mapping

By Phil Factor,

http://www.adobe.com/newsletters/edge/october2008/articles/article2/images/fig02.jpgTo 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.

Total article views: 342 | Views in the last 30 days: 1
 
Related Articles
FORUM

database properties not accessing

database properties not accessing

FORUM

SQL Server 2005->Problems while changing restrict access property from Restricted_User to MULTI_User

SQL Server 2005->Problems while changing restrict access property from Restricted_User to MULTI_User...

FORUM

Identity property problem

Identity property problem

FORUM

Problem accessing linked server

Problem accessing linked server

FORUM

Linked Access Database Problem

Extracting a row count of each table in a linked Access Database

Tags
editorial    
 
Contribute

Join the most active online SQL Server Community

SQL knowledge, delivered daily, free:

Email address:  

You make SSC a better place

As a member of SQLServerCentral, you get free access to loads of fresh content: thousands of articles and SQL scripts, a library of free eBooks, a weekly database news roundup, a great Q & A platform… And it’s our huge, buzzing community of SQL Server Professionals that makes it such a success.

Join us!

Steve Jones
Editor, SQLServerCentral.com

Already a member? Jump in:

Email address:   Password:   Remember me: Forgotten your password?
Steve Jones