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.

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.