views:

249

answers:

2

I've had a discussion with a colleague about "Linq to SQL". I am still new at .NET so he thinks I need to learn more. (still, 30 years of general programming experience should count in my advantage, right?) I had read some books and for a new project I decided to use the ADO.NET Entity Data Model. My colleague disagreed because he "knew" that entities had lots of problems. It caused memory leaks at the database server and Microsoft is going to discontinue it anyway. He told me I should use a Data Module instead. Just add a .dbml to my project and use Link on top of this.

He has 5 years of .NET experience, which is 4 years more than my experience.

I stopped myself so I wouldn't call him a moron or idiot or whatever because it appears to me that he thinks that "Link to SQL" == "Entity Data Model"...

Still, I started to have some small doubts. I thought that Linq to SQL is based upon .dbml files, thus based upon data models. And I've heard that Linq to SQL does have a few technical problems and that it's soon to be replaced by the Entity model. If my colleague mixed these two up, then he's an utter moron. But since he has 5 years of experience and since I doubt that my employee would even hire morons, I started to have doubts.

So, what is "Linq to SQL" exactly?

+17  A: 

LINQ to SQL and the Entity Framework aren't the same thing, certainly.

They're basically different ORMs, both from Microsoft and both acting as LINQ providers. LINQ to SQL was introduced with .NET 3.5, and the Entity Framework was introduced in .NET 3.5 SP1.

It's true that Microsoft is taking the Entity Framework forward in preference to LINQ to SQL, although many people in the community are urging them to improve LINQ to SQL anyway - it's a simpler framework than EF. In response, Microsoft has said it's going to try to make EF easier to work with when only simple models are required.

LINQ to SQL only works against specific databases - SQL Server and SQL Server CE, mainly. The Entity Framework is (at least theoretically) more database agnostic, so database vendors can plug in their own providers.

Jon Skeet
Great answer! I'd just like to address the "memory leak" Alex's colleague's mentioned. ORM's don't access the database in any special way. They perform SELECT, UPDATE and INSERT statements like everyone else, they just convert the results to object on their side (and not the database). Since the database wouldn't even know that an ORM is querying it, how would an ORM cause a memory leak any more than other users? In my experience, knowledgeable people might unconsciously guess, assume or 'fill-in' gaps in their knowledge (I know I do), which could sometimes lead to saying inaccurate things.
Allon Guralnek
Jon, do you actually have a job? I see you posting fantastic answers all over the place, great work for the community.
Jason Short
@Jason: I do, but not on Saturdays :)
Jon Skeet
+2  A: 

If your friend was suggesting that LINQ to Entities is going away, he's got it backward:

LINQ to SQL will continue to be supported but not extended much going forward. LINQ to Entities is here to stay and is Microsoft's preferred data access framework for .NET.

Dave Swersky
+1 So important to this discussion!
madcolor
+1 indeed! Plus, it concludes that my colleague is a moron since an experienced .NET developer should know the difference. Oh, well... I managed to get him off my back by just plainly stating that I am continuing to use entities, at which point he decided to stop interfering.
Workshop Alex