ADO.Net Entity Framework

I'm currently reading the documentation for ADO.Net Entities Framework. As always, I'm using this as a scratch pad for what I think as I read this.

Next-Generation Data Access - June 2006:

• They still allow access to lower level services with the Entity Framework. Lower level is apperantely IDbConnection and IDbCommand. They mention the 80% brick wall, which is encouraging. The problem is that I don't like this solution. The framework should be flexible enough that I could plug in at all the important points and replace the functionality with my custom one. Using two ways to acess the data has a big "Don't Do Unless You Know What You Are Doing And Have Fasted For Three Days" sign over it with red blnking lights.
• Chapter 3 is slightly interesting, 1,2,4,5 are extremely boring. Going over unrelated details (such as SQL Server ACID guarantees, merge replication, or order entry from 20 years ago). I understand the concept of a problem statement, but this is taking it to a new level.
• Chapter 6 is about what they are trying to achieve. Admirable goals.
• Chapter 7 shows the XML mapping. I'm not a fan of XML, and that XML is defiantely not something that you would want to write by hand.
• One nice feature that I noticed is the ability to map several tables into a single entity. This has some performance implications, because of joins
• I don't like that immediately show how to escape from the framework and go back to working with SQL and untyped data.
• They mention WCFClient which sounds interesting. I'm not sure how that will work, the models are very different.
• From the document, it seems like SQL Everywhere is going to ship with this, and be the local cache for the framework.
• The MapProvider looks like it is the equilent of the ADO.Net driver. You apperantly get one for each DB provider. It looks like it provide quite a bit more, though. Mapping, eSQL (Entities SQL), etc.

Okay, that was the high level overview, let start on the real details.

The ADO.NET Entity Framework Overview June 2006:

• Oh joy! Three ORM frameworks. Linq to SQL, Linq to DataSet, Linq to Entities.
• I understand the need of simple examples, but this is wrong:
  
  where order.Status == "Pending Stock Verification"
  This is no data mdoel that I know. There is no need to start the bad habits in the documentation. 
• This is a new record. They managed to piss me off on the very first page. The code example that they give as the desired state doesn't even make sense. Check the seond part of the example (in page 6), they load all the products, regardless of the order that has it. No order will ever ship unless all the products are shippable.
• What about custom collections? I'm only 1/3 of the way, so it may appear later, but this is a very big concern.
• Page 10: What do they mean? No behavior inheritance? If you map a table to a set of related classes, you bet you will get behavior inheritance. It is one of the more powerful features on an OR/M.
• Sigh. It looks like this is much about providing a mapping layer between the database and the logical model, and getting uptyped results back. I'm not excited about this at all. This is where they are putting quite a bit of emphasis.
• Given that they create a new langauge to work with the data, why not make it compatible with the way Linq work and use from-select-where ?
• Check this:
  

  SELECT VALUE sp

  FROM AdventureWorks.AdventureWorksDB.SalesPeople AS sp

  WHERE EXISTS(

    SELECT VALUE o

    FROM NAVIGATE(p, AdventureWorks.SalesPerson_Order) AS o

    WHERE o.TotalDue > 200000)

  This query makes no sense to me at all, it is supposed to bring all the sales persons with a sale over 200,000. Is there a reason I need to know the foriegn keys between the two objects?
  The same query, expressed in HQL (Hiberante Query Languague) will look like this:
  

  SELECT sp FROM 

  SalesPeople sp join sp.Orders o where o.TotalDue > 200000
  Update 20:36: Fixed HQL Query.
  
•  This is the magic? Please tell that they are joking...
  
  ctx.GetQuery<SalesPerson>("some eSql Query");
  p.Orders.Source.Where("it.Status == 0")
  Where is the Linq stuff? It was mentioned briefly as the ideal, but I didn't see it since (page 20).
• A side note, I see a lot of code written like this:
  

  "SELECT VALUE "

  +
  "FROM AdventureWorks.AdventureWorksDB.SalesOrders AS o " +
  "WHERE o.Status = 0"
  C# has a multi line string. It bothers me to see that they are not using it.
• Okay, chapter 4 is titled "Linq to Entities", so I guess there is Linq magic there.
•  The Linq samples looks like I expected them too. So I guess that I worried for no reason.
• The Linq on DataSet stuff it just ugly on untyped datasets. The difference between untyped & typed is just amazing.
•  No word on the difference between Linq for SQL (DLinq) and Linq for Entities except that the mapping is done directly against the database and not against a mapping layer on top of the databse (oh, how the Architects are going to love this).
• It looks like that are two types of mapping: Database --> EDM, Database?/EDM? --> Classes. And yet I see no references to the database on the EDM, and plenty of references to the database in the classes mapping.

Overall, not really impressed. I guess I will have to wait until I have the real bits to play bit, but except from the Linq magic, I don't see anything really interesting. I do foresee quite a bit of confusion, though.

Print | posted on Saturday, June 17, 2006 4:17 PM