So an interesting post come up on Stack Overflow (which, if you're not into you really should be) which was on the idea of ORM's and whether why are they becoming popular.
I'm a big fan of ORM's and I find that the responses in the topic are very interesting. By and large the responses from people are for ORM's, but this negative response got me thinking. The author makes a very valid point that with an ORM change release for minor change (I use the term loosly as there's never such a thing as a minor change... EVER) result in a larger deployment than you'd likely see in a non-ORM system.
On a recent website I worked on we had several instances where we had to do entire DAL releases (which the ORM is obviously built into) just for minor but system-critical changes.
They may have only been a handful of code lines that were updated but to get the changes released it required a lot more work. You needed to get an environment into a production-mirror state, local the appropriate label in source control, branch, make change, test, release.
Admittedly the majority of these steps are required each time but with a sproc change you ultimately have less dependancies, so the chance of a major fuck up is drasticly reduced.
That said, I am a huge fan of ORM's, I'm a really big fan of LINQ to SQL and I think it's possibility for use within a DAL is high (as implied here). I've used several different ORM's in my time, with different levels of code generation. I like LINQ to SQL as it doesn't actually add anything to the SQL server (which also makes unit testing a snap!). We had an in-house tool that we used for quite a number of years which generated .NET classes from your tables and a series of sprocs to handle most CRUD operations. It too was good, but it ultimately lead to what I believe the fundimental mistake that happens with ORM's - the spread of business logic.
Often with projects you'll have people who are really good at SQL, and you'll have people who are really good at .NET. And more often than not you'll end up with them coding their business logic into their preferred language.
So you end up with some of the business logic stored in the database and the rest stored in code files.
This then poses a maintenance nightmare. Depending on your security practices it may not be possible to debug the sprocs from VS, or the developer maintaining may not understand .NET as well as the original author.
I'm someone who's not great on SQL, I can get myself into and out of most trouble on a standard project, but when it comes really complex components I'd much rather write a few delegates and have my ORM handle it than try and achieve it in SQL.
And any half-decent ORM should be expected to translate the code-based queries into the underlying language of choice.
ORM's are here to stay, there's no doubt about that and i believe they offer a great advantages in development time and provide a good medium for proper logic abstraction within a project.