<< On POUT | Home | JScript and HashTables... >>

ORMs... Their Real Benefit

This is kind of a strange post from me, but I've started thinking about some things in regards to ORM products due to my fun with LINQ To SQL.  First of all, I'm not sure LINQ to SQL has this benefit (I could definitely be wrong about this), but I'm pretty sure that LINQ To SQL Entities does have (again, I don't speak as one who knows).

The difference is caching.  I know that NHibernate has some strategies for caching your data, as does something like LLBLGen (I checked... I don't want Frans coming down on me).  I'm pretty sure SubSonic has it (although I've let some of my skills in that area lapse a little).

I would argue that this is the one thing that ORMs do better than custom made DALs.  Don't believe me!  Ok, let's think about it...

Both ORMs and traditional DAL layers offer the ability to abstract the database away from us.  I can simply make a call and get back an entity from the database.  What if I'm in a web app where I'm doing multiple things... I need to load up the data to present it, and I need to look up the data to repopulate an object and then make changes based on the data that has come in... or maybe I need to load some related object...  You get the idea.

Here's the part where ORMs excel IMO.  An ORM that supports caching will make a single SQL call and will cache that data for the duration of the web call.  That part is easy and a programmer carefully crafting their DAL will be able to manage the same effect (provided they are looking to optimize the code). 

Some ORMs (and probably not all) have the ability to cache within the entire web application which means that a single update to an object will be reflected across the entire application.  Again, this is possible for a conscientious developer to do... but it's starts to get a little more complex. 

What happens if you have a team of developers working with you?  Can you guarantee that the next time someone has to work in your file that the caching of entities will be appropriately handled... I doubt it (unless you wrote your own ORM).


Share this post:  Email | Digg This! | Stumble This! | Save to del.icio.us | Share on Facebook | Add to Live Favorites |
Print | posted on Monday, February 04, 2008 2:59 PM

Feedback

# re: ORMs... Their Real Benefit

left by Jimmy Bogard at 2/4/2008 5:45 PM Gravatar

For me, it's not having to hand-roll a bunch of boring ADO.NET boilerplate code.  Or being able to support multiple databases easily.  Or not having to write a stored procedure again.  Or putting domain logic where it belongs, in the domain layer.  Or having an infrastructure that supports DDD very well is a plus.

Second-level caches are pretty nice in that they're built-in to mature ORMs.  But they're still fairly straightforward to do with an identity map and a sprinkle of expiration policies.  I don't know if I'd call it their real benefit, but it is super-dee-duper icing on the cake.

# re: ORMs... Their Real Benefit

left by robtx at 2/4/2008 6:30 PM Gravatar

There are different levels and types of caching, some of which are actually "bad". Most ORMs have the notion of reference identity since you can query for the same instance more than once. They mostly achieve this by some method of tagging an identity to an entity, and then using that for an identity map through some session or context manager. If you're talking about EF (which has LINQ to Entities), look up Object Services and Object Context.

# re: ORMs... Their Real Benefit

left by The Other Steve at 2/5/2008 3:07 PM Gravatar

This is an interesting point.  I haven't really looked at Linq to Entities, but I have used the LINQ to SQL stuff.

In my case, what I really wanted was audit records to be set when I saved something.  Created, LastUpdated, etc.  When reading some of the discussion on Guthrie's blog about LINQ, he recommended wrapping your linq objects with a Service layer.  So instead of calling the datacontext directly, you use this service layer which calls datacontext and works on the model.

Now this works, and using this service layer I could even add in some caching logic.

The problem I have is I haven't figured out how to make this generic.  I'm basically writing the same code over and over again for each model.  I need to wrap my head around this a bit, as I ought to be able to inherit.

I guess maybe the real root of my problem is that when I edit the linq mapping in VS.NET... if I make signifigant changes to the database and want to regenerate, I have to go back in and make all those edits again.  I need to figure out how to do this outside the wysywig.

# re: ORMs... Their Real Benefit

left by jkimble at 2/5/2008 4:04 PM Gravatar

Some would tell you that being able to edit outside the GUI is the problem...

I guess the real point is that I can now see the benefits of ORMs versus traditional code-generated DALs. (That's a huge step for me!)

I have seen some things over at Rick Strahl's blog that make me pause and consider that I might want to use something else.  

Caching isn't built into LINQ to SQL or EF... well that's not entirely true.  The DataContext and ObjectContext aren't really thread-safe (at least from what I read).

This isn't a huge problem for WinForm guys, but people using it off of ASP.NET might have a few issues.

The cruxt of the matter is this.  You should hang onto your references to the DataContext, but rolling back is not really possible (you simply recreate the DataContext... according to Rick Strahl that is).  So how do you "hang onto the reference" or do you do like I did in my example and simply generate one whenever you need it, and hang onto it for the duration of your atomic request.

Anyway, this sounds like a discussion for another day...

Title  
Name
Email (never displayed)
Url
Comments   
Please add 8 and 5 and type the answer here:
div>
Copyright © Jay Kimble