1/16: Updated with corrections from Readers.
I’d hoped to completely avoid any discussion surrounding the future (or futures) of Entity Framework and Linq2Sql. And yet, my LINQ talks at CodeMash got hijacked with questions about these two libraries.
I tried to sidestep, but there was no hope. Stephen Forte already proclaimed LINQ to SQL dead. What more could be said?
Well, I do hope it’s not as simple as that sound bite, so here are my thoughts.
There’s no doubt that Microsoft will have one data access strategy. There’s also no doubt that the name for that single data access strategy is Entity Framework. (Source)
However, I don’t believe that means concepts, designs, and code from LINQ to SQL won’t be part of that overall strategy.
I prefer Linq 2 SQL now
Entity framework supports a high level of abstraction. LINQ to SQL supports a wide breadth of abstractions. That, in my mind, makes LINQ to SQL a better design.
For example, consider lazy loading. Many people have noted that Entity Framework does not enable developers to specify lazy vs. eager loading at this time. L2S does: You can specify that certain relationships should always be followed for an entire application. (See DataContext.LoadOptions, and DataLoadOptions.LoadWith, or DataLoadOptions.AssociateWith). You can also change these properties at runtime, so you can specify eager or lazy loading on a query – by – query basis.
EF does support lazy and eager loading now: Its in the .Include("EntityName") on the query. Thanks Diane.
Another example is the DataContext.ObjectTrackingEnabled property. As you can logically guess, there is some overhead associated with tracking object IDs to correctly track changes on objects back to the changes in the database. You don’t want to pay that penalty if a particular application is only querying data, not changing it. Set ObjectTrackingEnabled to false, and watch your application speed up. (As always, measure changes meant to improve performance, or you are not doing engineering).
L2S also supports ways to execute dynamic SQL, or execute stored procs. I don’t start using either of those immediately. However, it’s valuable to know that there are options when the default behavior doesn’t meet expectations in a particular scenario.
Update: Entity Framework does support Stored Procs and Entity SQL, just not T-SQL (Also from Diane)
And all those points above are examples of the larger design decision: L2S supports a high-level abstraction, but provides ways to use a lower level abstraction when your application requires.
The Evil Enterprise
Entity Framework is an enterprise level framework that was specifically designed to work with large, existing (some may say legacy) databases. Personally, I believe that every scenario being optimized by the EF team begins, “So you have this database…”.
Too many of our customers are in the startup, or emerging company phase. Greenfield. No existing storage model. Furthermore, our projects are lean projects. The storage schema (whether database or file based) will be changing every iteration. At least until some release milestone is reached. Entity Framework doesn’t make those scenarios productive yet. They are possible, but they are not productive. These issues are worsened when multiple developers are accessing entity framework model source at the same time.
My opinion, but it seems like EF is targeting developer groups that work more in silos: “The Database Developer”, “the middle tier developers”, “UI Design teams”. We don’t work that way: Lean teams assign work to cross function and deliver slices of value. In one iteration, developers will modify the database, create business objects, and tie those to extensions at the UI layer. EF seems to have been designed around teams that have horizontal roles.
Diane says that EF can regenerate the entire schema, and that's true. My issue is that the manner in which EF writes a new model is very painful for tools like source control, and diff management. make that painful. If you're currently using a source control system that supports concurrent checkout, the EF regen model doesn't work.
Do I use LINQ to SQL in new projects?
I do. I know I’m taking some risk, but here’s my analysis, and my reasoning:
First and foremost, LINQ to SQL suits my needs better than EF v1. That’s the most important. Any project I’m starting now will certainly be modified, changed, and updated in the future. I’m willing to buy a future migration for the increased productivity now.
Second, I don’t believe LINQ 2 SQL is a dead end. I believe it will be an onramp to a future (IMHO better) version of EF. This is purely my opinion, and I watch for signs from the EF team, but I don’t believe the functionality in LINQ to SQL that is not in EF will be unceremoniously dropped. I do believe the EF team will have some migration strategy, and will incorporate those new features in EF in some meaningful way.
Third, I believe I have plenty of time. Microsoft is not going to stop including LINQ to SQL in the .NET framework until they are convinced EF is a good migration target for all the current LINQ to SQL users. That day has not arrived. Therefore, I believe I have plenty of time to be productive with LINQ to SQL before I must make a change. I’ll keep looking at EF with each new release. When I see reason to move my existing LINQ to SQL investment to EF, I will do so.
Fourth, I have options. If I find some future where LINQ to SQL ceases to be supported, and I’m still not happy with EF, I would consider Castle ActiveRecord, NHibernate by itself, or some other technology. If for no other reason than these options, Microsoft will not abandon LINQ to SQL without a migration strategy that make Entity Framework the obvious choice for those customers already using LINQ to SQL.
Fifth, in most of our applications, the data access layer is smaller than many other portions of the application. And, we try to keep it from leaking throughout the application. It’s a non-zero cost, but we try to keep the cost of changing the data access layer small.
Time for a big finish now
Entity Framework is a v1 product. LINQ to SQL is a v1 product. They targeted very different work patterns. Both those can be supported by some future version of Entity Framework. Until then, LINQ to SQL suits my needs better. That’s what I’ll use until the road map is clearer. I’m sure I’ll be able to leverage that investment in one form or another. I’m not on a dead end. I’m on a parallel path that will merge onto some future platform.