I used to think they were junk based on the examples I'd come across in my wanderings. However, after tinkering with LINQ to Sql I was forced to reconsider.

I think I feel about the same way about OR/M as I do about native CLR support in SQL Server... It's great IF the person using them understands the entire pipeline. It's terribly, terribly dangerous in any other scenario.


Also, I figured I'd comment on how LINQ to SQL addresses the list of costs mentioned above. I fired the same salvo when I was first researching it and was pleasantly surprised by what I found:


-Time to setup the ORM solution, troubleshoot if problems (likely)
Open up Visual studio. Point it datasource. Drag and drop on to OR/M Surface. Profit.

I can build a barebones DAL in about two minutes.

-Time to learn to use the ORM tool
If you know Lambda, you know how what LINQ is doing to your statements. If you know SQL, you already have an idea how to put those statements together in the first place. If you know Lambda very well and SQL reasonably well, you can even mix and match between various syntax styles according to your liking.

-Difficulty of finding someone who knows the ORM tool you use (vs finding anyone who knows SQL...)
It's baked in to the .NET framework.

-Additional cost of paying someone to learn or ramp up to learning the ORM tool you use, if needed
Same deal.

-Time required to tune performance
Takes about the same amount of time to tune a LINQ deal as a normal query. And, if need be, you can just make your fancy high performance view/sproc/what-have-you available to LINQ with another drag and drop.

-Decreasing quality of support over time for the particular version of your ORM tool, as new versions appear
This is the subject of some debate as it's still a little hazy about the relationship with Entity Framework.

-Time required to upgrade your ORM tool if needed because the version you use is too far out of date to get adequate community/pro assistance when needed
Install .NET. Done.

-Loss of entire database-specific features that a SQL solution designed by a DBA would have been able to take advantage of, due to the attempt of ORM to be "database independent" (which is rarely even needed)
LINQ to SQL only targets MSSQL. You can make use of pretty much all platform-specific features.

-Possibility of bugs in the ORM tool, and time lost tracking these down if they occur
Possibility of bugs in the homebrew DAL...

-Performance penalty of using the ORM tool
What might that be? Once we get in to the actual application side of things you're either abstracting out data access or you're not. You're paying the price regardless of whether that abstraction involves an ORM tool.

-Additional cost of hiring more highly skilled maintenance programmers to maintain ORM applications, vs hiring more entry level programmers who know SQL
You don't need highly skilled programmers to maintain LINQ to SQL applications. That's kind of the point.

-Increased demand on application server memory and processing requirements
Ever run the numbers on building an app server vs. a database server? It's much, MUCH cheaper to throw hardware at the app side of things. You also generally get much better control over fine grain memory management in an environment that is specifically designed for you to be instantiating and disposing of objects all the time.

-Minimization of database caching, in favor of ORM tool application server level caching--a particularly interesting topic when in a multi-app-server environment (heck I've even heard that some ORM tools don't update the database immediately, essentially making data in the database stale when accessed via a different application server)
n/a. You actually get more caching options in addition to what you're used to seeing.

-Inability (or additional time required?) to fine-tune queries to not pull back unneeded data (vs sql, simply select fewer columns)
Mark a property as lazy load and it won't be retrieved over the wire until it's actually accessed by the application. You get that for free.




Those were roughly all of my criticisms on the overhead of an ORM before I did this LINQ business too. Those are the answers I've found so far.


Oh, and in the spirit of objectivity, I should mention the a major failing I've found in LINQ is dodgy support for many-to-many joins.