I took a much needed break (mental and physical) from sitting in front of my computer fighting with a chapter that has been a bit of a challenge for me, and cajoled my husband into taking me for a walk. It's finally a beautiful day, about 70 degrees (F), sunny, light breeze. We have trails quite nearby our house that go up to the Long Trail, so went over to the one on the next road and hiked up to the shelter that is a stopping point along the trail, had a snack and hiked back down. It's definitely the most bang for the buck we can get when we can't spend a lot of time playing.

I brought my camera hoping that there would still be some spring flowers and boy were there a lot. I think because it's been a cold spring, things are a bit delayed.

My neighbor said she saw a big patch of LadySlippers along this path. Didn't see too many but looks like someone picked one from here.  

My hubby at his finest.

It's always funny to google for a solution to a problem and find your own blog post pop up with the answer.

I had to use an Entity SQL JOIN query today and I just went back to Chapter 5 to get a reminder of how to construct them. It's not the first time I've taken advantage of what is currently my own personal resource.

Boy it's feeling like it. So many nuances when you start looking at inheritance, complex types, query view, definiing queries , many-to-many mappings and then there are stored procedures. I'm wondering if I should just skip all of that in my book and plan to write a book on mapping and another one on stored procedures?

Okay okay, going back under my rock to keep at it...

This isn't even new news, but it is somewhat new to me! I met Damien at an SDR back in October and had fun sitting with him before I headed to the airport as he advised me that I should probably just get off the fence and move to C# finally. The discussion was mostly around the fact that I won't code on the fly in C# when I do presentations because it's not my natural coding language and I know I"ll do something wrong like use parens in an array and not be able to see why the thing won't compile. He suggested if I was always coding in C# instead of mostly in VB and sometimes in C#, this wouldn't be a problem.

I think it was the first time I heard someone make this argument in an attempt to truly be helpful and serious, not desecrating VB or laughing as they talked; therefore it left me with a great impression of him.

So I was very happy to hear that he took at  job with Microsoft recently and is working on the LINQ to SQL team. He's a really bright young guy. They actually snagged a few of these guys from the SDR. Jonathan Carter was there and became a new hire shortly after.

But to me what is most significant about this is knowing that the LINQ to SQL team is hiring developers. That says to me that they are continuing to work on LINQ to SQL. I get asked about this a lot when I present. I see  questions in listservs and on blogs - if LINQ to SQL is done and Microsoft is going to make everyone who has fallen in love with LINQ to SQL use Entity Framework instead - even if they don't want to. Even Roger Jennings  questioned this in a deeply analytical blog post. (I'm starting to wonder if Roger moonlights as a trial lawyer. )

I have even seen suggestions that LINQ to SQL was intentionally cobbled and done so for political, not technical reasons. I dunno, maybe I'm just too naive; but I find that hard to believe. OTOH, I have worked for myself for nearly 20 years, so I am a little out of touch (and very happily, at that!) when it comes to corporate politics.

But I really don't believe that this is going to happen. I do believe that LINQ to SQL will evolve and, like datasets, remain a completely viable choice for data access in .NET. I can't say why it didn't get a lot of attention for SP1, but comparing it to the fact that Entity Framework has been developed out of band and therefore introduced a lot of new stuff between Beta3 and the RTM version that will be part of SP1 is comparing apples to oranges.

So knowing that they are getting fresh blood (and I don't mean warm bodies) in the form of developers on the LINQ to SQL team is, to me, an indication that the product will continue to evolve.

And of course, thanks to my memory of that conversation last fall, I have already suggested to Danny Simmons that he task Damien with writing some VB samples! Hee hee.

I was getting ready to suggest this feature because it's a pain to "move" properties if you are deriving types or doing entity splitting.

I actually use the method of going into the EDMX file and copying the properties around in there so that I don't have to worry about the attributes and facets. Especially when I have a lot of properties to move.

Just out of curiosity I right clicked on an scalar property in the designer and saw Copy on the context menu, so I clicked it. Then tried pasting it into another entity and VOILA! Not just copy and paste; but cut, copy and paste

The funny part is that may have existed in the previous bits but I never noticed it before.

I can go shorten my book by a whole page now!

(I also want you to know that I was a good girl and removed "Holy Crap!" from the blog title and replace it with exclamation that is there now.)

The SP1 Beta does not include updated documentation for Visual Studio 2008, but it is all online.

You can start here: http://vs2008sp1docs.msdn.microsoft.com/en-us/default.aspx

A direct link to EF documentation is: Entity Framework

The tools documentation is not contained within there. Instead it is here: Entity Data Model Tools

The Astoria documentation is here: ADO.NET Data Services Framework

To me the most helpful thing is to see where it lives in the hierarchy so here's a pretty picture

Check out Ryan Hauert's blog!

Only two EF posts so far, but based on his busy postings in the forums, I imagine there will be more...

While I was in the middle of a flurry of conference prep and travel in April, I got an email pointing me to an interesting blog post by Dave DeWinter who is using T4 Templates to generate entity friendly CUD stored procedures. Why "entity friendly"? Because of a number of rules enforced by the model such as:

If you are using Stored Procs to do function mapping to an entity, you must use all three operations: Insert, Update and Delete.

if you have an association, the foreign key (aka the ID through the navigation property, e.g. Customer.Address.AddressID) must be used in all three (Insert/Update and Delete) stored procedures

If you do function mapping for a single entity in an inheritance hierarchy, you must have mappings for all of the entities except for abstract base types in the hierarchy.

I have been fighting the concept of modifying the database to enable the model (yeah - call me data-centric yet again and call em "she who worries about annoying the DBA" even though all of the DBAs I've ever met are pretty easy going)) but something has to give somewhere.

Dave and Ryan Hauert (who has been very active in answering forum questions for EF as of late!) are very pleased with the results of their templates.

Interestingly, at DevConnections, Danny Simmons was talking about providing functionality like this in a future version of Entity Framework.

So I'm going to go check this out, and play with it a little bit and see how it goes.

Can somebody tell me why CNN thinks this is a good idea? (Besides the profit motive...)

I've been spending a lot of time futzing with stored procedures in Entity Framework and losing sight of the fact that one of EF's core features is its ability to do query processing - and that is something it does very very well.

The Stored Proc support is obviously critical for many and while it's there, some scenarios are pretty easy to pull off, while many others are possible  but not so easy to implement and that can get frustrating.

What I'm trying to do is just truly see which things are easily pulled off in the designer (and discovering more than I realized), which are doable and which might take a hack or two to get around.

I think that in my case I was focused on the trees and forgot the the forest.

Thanks to the person who helped remind me of that.

Scott's a pal, promoting my book and my workshop on twitter!

Matthieu Mezil is a Parisian who really digs .NET and the Entity Framework. He writes a lot about it in his native tongue (that would be French ) in his blog.

Since my French, which I studied for 4 years in high school and college (which was a long, long time ago) is pretty rusty, I use google's translation to get a gist of what he is saying in his blog.

But now that Matthieu is an MVP, he has started a mirror blog in English on the msmvps.com/blogs site.

So to recap

Matthieu Mezil in French

Matthieu Mezil in English

I hadn't noticed this before.

If you have a stored procedure that is mapped to an entity such as "GetCustomersSince" which returns Customer entities, the command is executed when you create the query, not, like with normal queries, when the data is first needed.

In case that sentence was too convoluted...

Here is a LINQ to Entities query (the same is true for LINQ to anything and also for Object Services (context.CreateQuery))

Dim query= From c In context.Customers Select c

For Each cust in Query  <-- command is executed here

'do something

End For

But when calling a function import:

dim custs= From c in context.GetCustomersSince(New Date("2008","01","01")) <--command is executed here

For Each cust in custs

'do something

End For

Looking at the code gen for the function I can see that ObjectContext.ExecuteFunction is called.

I'm definitely interested in what people have to say about Danny's post so I have subscribed to the Bloglines citations of it:

http://www.bloglines.com/search?q=bcite:blogs.msdn.com/dsimmons/archive/2008/05/17/why-use-the-entity-framework.aspx

RSS

Don't forget the comment thread in Danny's post as well.

Not surprisingly, the folks who have already made it clear that EF is way too data-centric for them are up in arms and there are some very interesting discussions in their blogs (as well as the comment threads).

I'm not sure if I would compare the investment I am making in understanding how EF works and writing a whole book to share what I've learned to being brainwashed by a "shiny brochure on your desk". Nor do I feel like a "cheerleader" or "parrot". But... whatever... (lame response? Yep! But it's all I have time (or patience) for).

Michale de la Maza follows up his popular C# day events with a VB.NET day at the Microsoft office on Tuesday May 27th.

Join us for a relaxed, no cost introduction to VB.NET programming. By engaging in participatory activities, you will learn some of the most common and powerful features of the VB.NET language. This day is not lecture-based. There will be fewer than 60 minutes of lecture material -- almost all of the time will be spent on participant-guided activities. Everyone who attends will learn what interests them at their own pace in a relaxed, tension-free environment with an experienced VB.NET developer and trainer available to answer questions.

RSVPs are required and details are here.

The online registration system for Microsoft events is currently broken (or just acting really flakey).

If you are trying to register for Thursday’s free, full-day, Bob & Chris & Jim Roadshow , try the online registration first here:
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032378634&culture=en-US

If that doesn’t work, you can register by phone

Call the event system directly (877.673.8368) and use the event ID 1032378634.

For more information and details about the event, see Chris’ blog post here:

http://blogs.msdn.com/cbowen/archive/2008/05/02/the-roadshow-rides-again-may-june-edition.aspx

If you are trying to register for a different one of these Roadshow events, just get the EVentID from Chris' blog.

If you are trying to register for other Microsoft events the phone # should be the same, but you'll need to know the EventID of the event you are trying to register for.

In the earlier bits, if you changed an association to an inhertiance, the type that becamse the derived type lost its mappings and th emappings for any associations.

Depending on how complex that type is, recreating all of that could be challenging.

I just tried this out in the new bits and the mappings and association mappings all remain intact.

This is great and it will save a tree too, since I can go remove all of that explanation about how to deal with that problem from Chapter 5 of my book!

If you have screwed up your Entity Data Model, you may be familiar with safe mode when you try to open the model up in the designer.

But the mapping designer has Safe Mode now, too.

Here is what I get when I am in the middle of creating an inheritance in my model which means that some of my mappings are still a big goofy. I tried to get to the mapping details of the derived type and here is what I see:

The error messages for Entity Framework and the designers are really very helpful.

Over a year ago I asked a question in the EF forums about being able to use strings in conditional mapping.

It is now possible! Yay.

Having just done a presentation at DevTeach called ".NET 3.5 Data Access Guidance", which I will be doing again at TechEd in a few weeks and I have a CoDe Magazine article on this topic coming up as well, it is definitely interesting to me to see what is probably the first somewhat official looking (it's a blog post, not a white paper) guidance from someone at Microsoft about Why to use Entity Framework.  Outside of a direct comparison of LINQ to Entities vs LINQ to SQL by Elisa Flasko earlier this year , there hasn't been a Microsoft white paper on Entity Framework since June 2006. That's almost 2 years. And that was written when they were first going public with the technology. What Danny is doing here is definitely a first.

In my presentation/article I need to be objective. Granted I am only addressing what's "in the box" - datasets, LINQ to SQL and EF, not nHibernate/ORMs. And I have to be sure not to lean towards EF, which is difficult not to do since I am so focused on it.

But Danny's list is definitely right on. He is highlighting the benefits of EF compared to datasets, compared to LINQ to SQL and also compared directly to nHibernate. It's funny how we (Danny, myself, maybe others) tend to include nHibernate, which has a LOT less users than datasets or LINQ to SQL in these discussions because it is the [relatively] small # of nHibernate users that make the most noise and Danny and I have both been beaten up quite a bit by them, so we now have a natural tendency to be sure to address them at every turn. I think it's become self-defense measure more than anything else. (I shouldn't really speak for Danny here, since he may have different reasons. I know that this is true for me, though.)

One thing that I need to do differently than Danny's post when I do the overall guidance presentation is not just list the places where EF totally outshines the other options, but I also need to address areas where you may prefer the others.

Every time I have done this guidance presentation, I have had someone say to me after the fact, "but I really love typed datasets? Why should I move to EF or LINQ to SQL". My response to them is that if after seeing my presentation, if there is nothing that was truly compelling to them to want to make the change, then typed datasets are probably just the right choice for them.