I presume we’ve all used LINQ-To-SQL or perhaps still using it in some way shape or form; perhaps even supporting a legacy application that has a large footprint of LINQ-To-SQL.
In this short blurb, I’d like to compare the above with Entity Framework and how the two differ from one another. Now, it begs the question, should we be using one over the other? Why?
There is no question LINQ to SQL is a light-weight API and you can get up and running much more quickly than you would with Entity Framework. However, the main question is that are new features being added to LINQ to SQL? The answer is probably not! Even though, Microsoft continues to support LINQ to SQL in all its glory, their efforts are mainly restricted on developing the next version of Entity Framework, called EF7, the topic on which I have blogged earlier.
Although, I have used both technologies; I must say, while LINQ to SQL does provide out of the box solution in a rather quick succession particularly if you are using SQL Server 2000 or higher. However, I have found it to be flaky at times. This is especially true when adding new database objects onto the DBML designer, it sometimes does not generate the necessary classes and when it does, it does create an empty Return Type for a given database object e.g. a stored procedure. You can certainly fix it, but at the cost of your precious time!
My take is that if you are building a Line of Business application; consider investing some time becoming proficient in Entity Framework. Apart from a plethora of workflows it offers such as Code First, Model First and Database First, it’s versatile enough, loosely coupled, allows many to many relationships, inheritance, eager loading; just to name a few!!