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
Anonymous
June 21, 2006
Shyam Pather, a dev lead on the ADO.NET effort just posted on the Data Access Blog he has done some screen...Anonymous
June 21, 2006
Shyam Pather just posted a couple of screencasts on the Data Access blog.
The screencasts (part 1 here)...Anonymous
June 21, 2006
In case you missed it, Somasegar (Microsoft's VP of Developer Division) blogged today about some of the...Anonymous
June 21, 2006
Just some stuff I've noticed floating about and I think is worthy of note:
Pablo Castro points to...Anonymous
June 21, 2006
www.base4.net/Blog.aspx?ID=46Anonymous
June 21, 2006
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.Anonymous
June 21, 2006
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.Anonymous
June 22, 2006
If you write database applications using ADO.NET (which means almost everyone is still reading this),...Anonymous
June 23, 2006
How could i download these presentation ??Anonymous
June 23, 2006
Great stuff! I am sure you guys have considered this, but can you update or delete an entity without first retrieving it?Anonymous
June 23, 2006
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.Anonymous
June 23, 2006
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.Anonymous
June 23, 2006
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.Anonymous
June 23, 2006
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...Anonymous
June 23, 2006
The comment has been removedAnonymous
June 23, 2006
Since announcing our ADO.NET vNext plans at TechEd last week, the team has been on the lookout for your...Anonymous
June 25, 2006
The comment has been removedAnonymous
July 11, 2006
(this is post&nbsp;was originally posted here)
Hi - I'm Shyam Pather, Development Lead&nbsp;on the ADO.NET...Anonymous
July 11, 2006
(this post&nbsp;was originally posted here)
Since announcing our ADO.NET vNext plans at TechEd
...Anonymous
July 25, 2006
Shyam Pather, development lead on the ADO.NET team, has put together two interesting web casts about...Anonymous
August 27, 2006
Shyam Pather just posted a couple of screencasts on the Data Access blog . The screencasts ( part 1 hereAnonymous
September 28, 2006
Get much awaited ADO.NET vNext Entity Data Model Designer Prototype, CTP here (note: you'll need LINQAnonymous
April 02, 2007
On Saturday on March 31, 2007 I did a couple of talks at the Toronto Code Camp. The first an overviewAnonymous
March 27, 2009
Shyam Pather just posted a couple of screencasts on the Data Access blog . The screencasts ( part 1 here ) demonstrate the new features of "ADO.NET vNext" (or ADO.NET 3.0) like the new "Entity" framework and the accompanying "EntityAnonymous
May 31, 2009
PingBack from http://outdoorceilingfansite.info/story.php?id=5154