ADO.NET, LINQ, and the Entity Framework Oh My!

If you write database applications using ADO.NET (which means almost everyone is still reading this), then a MUST HAVE blog in your RSS reader is the Data Access blog. It is the “Data Programmability team blog for data access in ADO.NET and System.Data namespace.”

They recently blogged about ADO.NET vNext and our vision on data programmability. Again, if you write database applications using ADO.NET, then this is a MUST READ. I just finished reading it and (although I am clearly biased) I must say as a true geek I am excited and impressed by where we are going. Once you get the vision, you really should immediately follow up by reading The ADO.NET Entity Framework Overview. This is what you can expect to see in the next version of ADO.NET. In short, the Entity Framework allows you to define a conceptual data model on top of logical schemas. This is cool stuff! If you made it through all the reading and you’re still geeking out like I was, then watching the two screencasts which demonstrate this stuff in action will solidify your reading. That’s the path I took.

You may be thinking to yourself, “Ok Marc, this sounds like Object Relational Mapping stuff. Didn’t you tell me here that DLinq is the ORM piece of LINQ?” Yes I did. First, DLINQ is now LINQ to SQL. Soma talks about the renaming here. LINQ to SQL does in fact do object relational mapping. However, for the most part, it gives you the ability to represent concepts as objects. In essence, you have a CLR class that represents your table. If you have a logical entity, such as a SalesPerson, spread across multiple tables (ex: SalesPerson, Employee, Contact), then with LINQ to SQL you create a class for each table. Yes, there are more advanced mapping capabilities in LINQ to SQL, but your LINQ to SQL classes are very database centric (very much like strongly typed datasets). With the Entity Framework you have a higher level of abstraction on top of your database. Using the same example with the Entity Framework you can define a single SalesPerson entity which maps to the multiple tables. The entity is represented in a way some might say is much more object (domain model) centric (as opposed to the relational representation with LINQ to SQL). The Entity Framework allows you to create queries in something called eSQL (e=entity). However, I suspect the majority of folks will want to use LINQ queries with Entities for the same reasons you want to use LINQ to SQL. The core query experience of LINQ is fundamentally the same whether you choose LINQ to SQL or the Entity framework. In fact, it’s aptly named LINQ to Entities.

So why two approaches? Well, some people like programming in a very database centric way. Others like the domain model approach. I would guess that the thinking is that we as a platform company aren’t going to, nor should we IMHO, dictate your approach. That’s for you to choose. If you are in the database centric camp, I suspect you’ll like LINQ to SQL. If domain models make you smile, then you’ll probably like LINQ to Entities. And oh by the way, if you don’t want all this abstraction and still want to do database access the old way, it’s still there.

If you managed to read this to the end, then what are you waiting for?  Go read the two articles and watch the screencasts!

-Marc

UPDATE:  Sorry about the bad proofreading.  Should read a little better now.

Technorati Tags: Microsoft, .NET, Object Relational Mapping, ORM