ADO.NET vNext screencast


Hi – I’m Shyam Pather, Development Lead on the ADO.NET vNext team.


I’m incredibly excited to share some demos of ADO.NET vNext in action. By now, many of you may have read the whitepapers and blog entries describing the new features. In this pair of screencasts (Part 1 and Part 2) you’ll be able to see the developer experience of using these features in code.

In these screencasts, I start from a program that uses the ADO.NET stack we shipped in the .NET Framework 2.0. Using a preview of the upcoming ADO.NET vNext bits, I show how it can be evolved it to take advantage of the Entity Data Model, Entity SQL, new Metadata APIs, and LINQ. Most of the time is spent in Visual Studio, looking at working code samples.

Here’s a high-level breakdown of what you’ll see in Part 1:

0:00-2:25      Intro and demo of basic ADO.NET 2.0 code.
2:25-8:00      Creating a conceptual data model
8:00-12:30    Using the Map Provider to query with Entity SQL
12:30-16:05  Explicit relationship navigation in Entity SQL
16:05-17:50  Accessing result metadata via IExtendedDataRecord
17:50-21:55  Polymorphic Queries
21:55-23:40  Filtering on entity type at the server

Part 2 builds on this and covers the following additional topics:

0:00-6:15     Obtaining results as objects
6:15-9:34     Polymorphic queries with results as objects
9:34-11:53   Removing the connection handling code
11:53-14:48 Using LINQ to express queries
14:48-21:02 Adding and updating entities


You can access the screencasts from the following locations:



I hope you find this useful and look forward to hearing your feedback.

Shyam Pather
Development Lead
ADO.NET vNext

Comments (28)

  1. Shyam Pather, a dev lead on the ADO.NET effort just posted on the Data Access Blog he has done some screen…

  2. Mabsterama says:

    Shyam Pather just posted a couple of screencasts on the Data Access blog.

    The screencasts (part 1 here)…

  3. In case you missed it, Somasegar (Microsoft’s VP of Developer Division) blogged today about some of the…

  4. Just some stuff I’ve noticed floating about and I think is worthy of note:

    Pablo Castro points to…

  5. Kris says:

    I just watched both the demos. Interesting and very well presented. Couple of questions –

    1) Is this the same as DLINQ and LINQ? Aren’t they supposed to be core C# language features? Do they make use of ADO.vNext underneath?

    2)What is the level of performance loss when using the Entity model as against pure ADO.NET SQL queries?

    3) Is the E-SQL going to be an open standard? If not developers now have to learn additional constructs, not to mention J2EE has its own construct called – EQL. It would be nice if this is an open standard adopted by most major companies so it provides another database agnostic layer.

  6. Kris says:

    I just watched both the demos. Interesting and very well presented. Couple of questions –

    1) Is this the same as DLINQ and LINQ? Aren’t they supposed to be core C# language features? Do they make use of ADO.vNext underneath?

    2)What is the level of performance loss when using the Entity model as against pure ADO.NET SQL queries?

    3) Is the E-SQL going to be an open standard? If not developers now have to learn additional constructs, not to mention J2EE has its own construct called – EQL. It would be nice if this is an open standard adopted by most major companies so it provides another database agnostic layer.

  7. If you write database applications using ADO.NET (which means almost everyone is still reading this),…

  8. boingboing says:

    How could i download these presentation ??

  9. Marlon Smith says:

    Great stuff! I am sure you guys have considered this, but can you update or delete an entity without first retrieving it?

  10. Bill Burrows says:

    This is really GREAT stuff (and also a very well done demo). I’d like to see a little more on what went into building the entity model – will you have a graphical designer? Also, a query designer (using the entity model) would be a great asset for my use.

  11. Alex James says:

    How efficient is the Upcast in the loop in the second screencast? Is it a traditional CLR cast or is there some lazyloading occuring? Love to know the answer.

  12. Shyam Pather says:

    Alex, I posted a response to your question about the upcast on your base4 blog, but here it is again:

    In this scenario, the result objects are materialized to the actual type described by the metadata. So if an entity comes back with metadata saying it’s a StoreSalesOrder, it gets materialized as an instance of StoreSalesOrder. If the metadata says it’s a regular SalesOrder, then the materializer creates an instance of SalesOrder. In your characterization, this is option 1.

    Now, whether this is the right thing to do (based on efficiency) depends on the intent of the original query. If the app is asking for all sales orders and explicitly wants to deal with StoreSalesOrders in the result set differently than regular SalesOrders, then this behavior makes sense. The app will have access to the properties of StoreSalesorder and can manipulate them as needed.

    If the app only wanted to deal with the properties of SalesOrder, regardless of whether the entity was actually a StoreSalesOrder, then you are correct in your insight that materializing a StoreSalesOrder would be inefficient. The query would need to be formulated slightly differently to express this intent, but doing so would result in a more efficient result set. In your code snippet, you showed the LINQ form of the query, but I’m going to go back to the eSQL (Entity SQL) version first and return to LINQ in a minute. In eSQL, the original query was:

    SELECT VALUE o

    FROM AdventureWorks.AdventureWorksDB.SalesOrders AS o

    WHERE o.OrderDate < @date

    You could instead write

    SELECT VALUE TREAT( o AS AdventureWorks.SalesOrder )

    FROM AdventureWorks.AdventureWorksDB.SalesOrders AS o

    WHERE o.OrderDate < @date

    The TREAT operator can be thought of as a cast that gets evaluated at the server. The results that come back from the second query would have metadata that described each instance as a SalesOrder and therefore the materializer would only create instances of SalesOrder. If the app knew it would never want to deal with things as StoreSalesOrders, this would be sufficient. Note that sales orders that are actually StoreSalesOrders would still appear in the result set, but they would be materialized as SalesOrders, without the additional StoreSalesOrder fields. Alternatively, if you wanted the sales orders that were of type SalesOrder only (not any of its descendant types), you could add the following predicate to the WHERE clause:

    AND o IS OF (ONLY AdventureWorks.SalesOrder)

    If you did this, you wouldn’t need the TREAT in the projection, because every result would be guaranteed to be a SalesOrder.

    When we return to LINQ, this gets a bit more difficult to express. You could put a cast into the query itself, but this would just cast the reference, not change the runtime type of the instance. Another option is to create a new instance in the projection, like this:

      var orders = from o in aw.SalesOrders

                          where o.OrderDate < date

                          select new SalesOrder(o.OrderId, o.OrderDate, …)

    My understanding of the LINQ implementation is somewhat limited, so I may be wrong about this, but I believe the above query will do the right things with respect to object identity i.e. the identity is based on the key property of the object (OrderId, in this case) not on the reference.

    Hope this helps.

  13. Alex says:

    Well thanks for the quick response Shyam.

    I suppose whether you hydrate SalesOrders or StoreSalesOrders is quite arbitrary. I think I have always leaned toward hydrating as a SalesOrder… so it confused me, but as you rightly point out there are lots of situations where loading the actually object as described by the metadata makes sense.

    This does however make me wonder about the structure of the List of IExtendedDataRecords you get back under the hood. I kind of assumed for efficiency sake that in the API,a list of IExtendedDataRecords would share the same MetaData (i.e. only one copy of meta-data required for all records) however because in this situation each IExtendedDataRecord can be a different shape I assume that each record has it’t own metadata.

    Hmm…

  14. Shyam Pather says:

    Some answers to questions posted above:

    To Kris:

    Q1) Is this the same as DLINQ and LINQ? Aren’t they supposed to be core C# language features? Do they make use of ADO.vNext underneath?

    A1) This demo shows LINQ to Entities which is different than LINQ to SQL (formerly known as DLINQ). LINQ to Entities exposes the C# LINQ features over data modelled with the Entity Data Model, whereas LINQ to SQL offers LINQ capabilities directly over SQL databases.

    Q2)What is the level of performance loss when using the Entity model as against pure ADO.NET SQL queries?

    A2)ADO.NET vNext generates the equivalent SQL for queries expressed in LINQ or Entity SQL. We are doing a lot of work to make these generated queries as efficient both by reducing their complexity and by caching the generated SQL so that we don’t go through the generation phase over and over again for the same query. Also, we are looking at ways to plug in stored procedure calls into the generated SQL so that you can take advantage of custom-written logic and query hints. As far as a direct comparison goes, we haven’t done a detailed analysis yet, but probably will once we’re further along with the optimization work.

    Q3) Is the E-SQL going to be an open standard? If not developers now have to learn additional constructs, not to mention J2EE has its own construct called – EQL. It would be nice if this is an open standard adopted by most major companies so it provides another database agnostic layer.

    A3) We are planning on publishing the eSQL spec soon (we’re just finalizing some last details). It’s a bit early to talk about standardizing the language, but the spec will certainly be available. Regarding other database providers, they can plug into the ADO.NET vNext stack simply by writing a custom SQL generator that takes a query as a command tree and outputs a provider-specific dialect of SQL. This means that they do not need to write an eSQL parser to expose eSQL capabilities. The ADO.NET vNext stack was specifically designed with non-Microsoft providers in mind. We’ll eventually have a sample that shows what provider writers will need to do to plug into the Entity Framework.



    To Marlin Smith:

    Q: “…can you update or delete an entity without first retrieving it?”

    A: In V1 we are targeting only updating instances that have been retrieved. Query-based update is something we are looking at for a future version.



    To Bill Burrows:

    Q: I’d like to see a little more on what went into building the entity model – will you have a graphical designer? Also, a query designer (using the entity model) would be a great asset for my use.

    A: In an upcoming Channel 9 video, you’ll get to see a prototype that illustrates our thinking on graphical tools for building an entity model and mapping this to a store.

  15. Since announcing our ADO.NET vNext plans at TechEd last week, the team has been on the lookout for your…

  16. (this is post&amp;nbsp;was originally posted here)

    Hi – I’m Shyam Pather, Development Lead&amp;nbsp;on the ADO.NET…

  17. (this post&amp;nbsp;was originally posted here)

    Since announcing our ADO.NET vNext plans at TechEd

  18. Shyam Pather, development lead on the ADO.NET team, has put together two interesting web casts about…

  19. Mabsterama says:

    Shyam Pather just posted a couple of screencasts on the Data Access blog . The screencasts ( part 1 here

  20. Get much awaited ADO.NET vNext Entity Data Model Designer Prototype, CTP here (note: you’ll need LINQ

  21. On Saturday on March 31, 2007 I did a couple of talks at the Toronto Code Camp. The first an overview

  22. Mad Props! says:

    Shyam Pather just posted a couple of screencasts on the Data Access blog . The screencasts ( part 1 here ) demonstrate the new features of &quot;ADO.NET vNext&quot; (or ADO.NET 3.0) like the new &quot;Entity&quot; framework and the accompanying &quot;Entity