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.
You need to think of LINQ to SQL as an abstraction above writing SQL directly yourself. If you can get your head around this then you’ve made a step in the right direction. You also need to let go of some long held beliefs such as compiled sprocs are always faster and SQL accounts shouldn’t have data reader / writer privileges.
I’ve found that it’s possible to begin gradually moving existing solutions towards LINQ to SQL so long as there is a clear DAL in place and you’re just changing the implementation without affecting the contract it may have with consuming code. Reference lists are an easy candidate as they’re low impact, read only sets of data. The main thing you need to remain conscious of if retrofitting is potential ambiguous class names if you’ve already hand coded them to model the database.
With the value of hindsight in bringing LINQ to SQL into a large enterprise (since CTP days), I’d do it again in a heartbeat. It’s not perfect and there are issues but there are enormous benefits particularly when it comes to development speed and maintainability. It’s a new paradigm and is definitely, definitely a step forward.
I undertand your point, this does indeed seem like a bit of a backward step...
Actually I would probably steer away from LINQ to SQL and look more at LINQ to Entities, your entities model your conceptual data model and I personaly feel more comfortable embedding queries agains a conceptual model in my code. The actual physical model is abstracted away from you by an entity framework.
This link (excuse the pun) discusses LINQ to Entities and the Entity Framework: http://msdn.microsoft.com/en-us/library/bb386992.aspx
This is an interesting article discussign the pros and cons of both approaches: http://dotnetaddict.dotnetdevelopersjournal.com/adoef_vs_linqsql.htm
Edit Another thought, if you don't want wait for EF, have a look at NHibernate, you can LINQ to that too... See http://www.hookedonlinq.com/LINQToNHibernate.ashx
There is an implementation of LINQ to SQL not only for SQL Server databases, so the non-SQL Server developers can also take advantage of using this efficient ORM. We have already added support for query-level LaodWith( ) and extended the error processing. Also we plan to support all three inheritance models (TPH, TPT, TPC) and key field generation. You can find the list of supported databases here
I don't think of it as embedding SQL in your code any more than embedding a Stored Proc name in your code is. More often than not a change to your Proc involves change to your code anyway. For example, you usually need to add a new in/out parameter or update a getter/setter method to reference a new column.
What it does is remove a lot of the leg work of writing twice as much code to align properties and methods in your code with procs and columns in your DB.