I’m considering spending time learning and using LINQ to SQL but after years of best practices advising NOT to embed SQL I’m having a hard time changing paradigms.
Why does it seem accepted now to embed queries in compiled code? It seems almost a step backwards to me in some ways.
Has anyone had issues with fix query / compile / deploy cycle after switching to LINQ?
I think I still might wait for the finished Entity Framework.
What do you think?
The advantage of Linq to Sql is that it doesn’t really embed queries in compiled code – not really. The Linq statement means that your .Net code actually has the logic required to build the Sql statement embedded, not the raw Sql.
It really makes a lot of sense to have .Net code that converts directly to the Sql to execute, rather than a long list of sprocs with associated documentation. The Linq way is much easier to maintain and improve.
I don’t think I’d switch an existing project to Linq – really it’s a replacement for the entire data-layer and it can change the way all access to that layer is done. Unless you’re switching from a very similar model the cost is going to be far too high for any potential gains.
Linq to Sql’s real power is in quickly creating new applications – it allows you to very rapidly create the data-layer code.