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: , , ,

Comments (3)

  1. Paul Wilson says:

    I like to think of myself as both database centric and domain model centric — so where does that leave me?  Maybe that sounds bizarre, but my experience as someone that develops a popular O/R Mapper is that its actually quite a common thing.  How can one be both?  That’s easy — I design pretty much my database and domain models concurrently, with my eye on both database efficiency and domain simplicity.  I would suggest that those that over-focus on only one of these extremes is simply not experienced in both aspects, while those that are experienced in both database design and object design prefer both/and to either/or.

  2. FederalDev says:

    I couldn’t agree with you more Paul.  I find, too often, people are looking for a "silver bullet" technology to solve all of their problems.  It’s all about using the right tool/technology for the right job.  I think the beautiful thing about LINQ is not having to choose only one data representation.  It works with objects, XML, DataSets, Entities, LINQ to SQL classes, etc.  Use as many as you feel get the job done correctly.  

    I find that you are in a unique camp.  Most people I run into seem to be staunch supporters of one or the other.  

    BTW, I’m a big fan of your O/R Mapper.  I used it (before coming to Microsoft) on a solution that originally used ObjectSpaces.  Very smooth transition.  Great stuff.

    -Marc