The MSDN forums for data access have been restructured a little.

Entity Framework & LINQ to Entities questions:

The one which has always been under “MSDN Forums » Visual Studio 2008 (Pre-release) » ADO.NET (Pre-release)” has been renamed to MSDN Forums » Visual Studio 2008 (Pre-release) » ADO.NET Entity Framework and LINQ to Entities (Pre-release). It’s still pre-release, of course.

LINQ (Released)

While there is still a general LINQ forum under MSDN Forums » Visual Studio 2008 (Pre-release) » LINQ Project General  (Yes, under Pre-Release. I imagine they don’t want to lose the content or confuse people by moving the forum), the LINQ “flavors” have now been split up and are in the “Data Platform Development” section.

MSDN Forums » Data Platform Development » LINQ to SQL  
MSDN Forums » Data Platform Development » ADO.NET DataSet (This includes LINQ to DataSet)
MSDN Forums » Data Platform Development » XML and the .NET Framework   (This includes LINQ to XML)
 
Regular ADO.NET (aka “Classic”)

1) The above linked ADO.NET DataSet forum is the place to go for all things DataSet.
2) MSDN Forums » Data Platform Development » ADO.NET Data Providers  
“Data platform development using classic ADO.NET (v 1.1 and 2.0) and System.Data namespace.”

EFExtensions , released on CodeGallery earlier this week by EF team member, Colin Meek, has a lot of brainy goo in it. So far I’ve looked at the pieces that Colin has explained in his first post (first post ever) about the Extensions. While most of the extensions in the first part of his post are replicating what Object Services does, the last chunk displays the real benefit of having them at hand.

EF Function Imports can handle READ stored procedures that return existing entity sets. At first I was looking at the extensions to see if they can return random objects, but I haven’t seen that yet however there’s a lot to look at still. (I’m picturing a generic method that reads the columns and creates an anonymous type on the fly rather than having to go through all of the mucking with the model to make this work. Of course, this is for read-only results.)

What Colin’s post shows, however is sprocs that return shaped results. A standard function import can’t do this…it needs to map to a single entity type.

So by combining a few of his extensions, he is able to extract the different types from the shaped results and mimic the object materialization that happens under the covers in expected scenarios. Additionally, he is able to add these entities manually into the change tracker.

It’s pretty sweet and what’s funny to me is that I was trying to do something very similar to this on the same day that Colin released the extensions. I had seen them pop into Code Gallery, made a mental note and a quick blog post without digging into them yet, then a few hours later asked on the forums, “Any way to grab sets of (unrelated) entities in one database call? “. Small world, eh? Now that I have a better understanding of some of the extensions, I will have to go back and see if this does the trick.

Is Entity Framework right for your Applications? You’ll probably want to answer this question before you start digging in deeply to learn this new data access platform that will be released very soon. Does it fit into my architecture? Will my DBA allow it? How will it play with my existing solutions? This BOF is intended as an interactive discussion where there will be plenty of experts in the room to get you started with some important decision making.

It won’t happen unless it gets voted for so go vote!

Roger Jennings wrote a dizzying (in a good way) post about stored procedures that I have not even had the chance to absorb yet but it’s about creating database procedures after the fact that can be easily used with the entities and associations defined in your model.

Coincidentally, Noam Ben-Ami wrote a lengthy post on teh ADO.NET Team blog about using the designer to leverage DML stored procedures that already map directly to entities defined in teh CSDL, while the stored procedures might do perform additional functions, such as time-stamp checking. Stored Procedure Mapping

In the EF forums, Danny Simmons lets an EF RTM cat out of the bag.

And, this looks like it has the possibility to be bigger than just for EF. The EF team worked with the WCF team to make ENTIRE GRAPHS serializable, and in an interoperable way. If you look at Ruurd Boeke’s blog post,Circular references with WCF: solved a different way, about how he  achieved this, you can see examples of how WCF serialized entities before (non-interoperable) and after his own tweaks. Ruurd has been thinking about this problem for a long time, not just for EF, but for WCF in general, because it’s the way that WCF serializes that causes the problem.

So the question is, did they just implement this specifically for EF, or will this have a broader impact? We’ll see when the next CTP (as per Danny’s comment, he says CTP not Beta4) of EF comes out.

It’s great to see Colin Meek finally blogging. Colin has been a wealth of information on the MSDN Forums for Entity Fraemwrok related questions. It is also COlin who posted teh Entity Framework Extensions on CodeGallery a few days ago.

Colin talks about the extension in his first post and how they can be used to handle a variety of Stored Procedure scenarios in Entity Framework.

For what looks like a pretty complete list of the blogs of the Entity Framework team and others on the Data Programmability team at Microsoft, see the Resources page of the DataDeveloper.NET website.

Thanks to Alex for the heads’ up….