Monday, November 24, 2008

Fun with Entity Framework

So despite spending the first 6 months of the year becoming proficient and LINQ to SQL, the realization that Microsoft was casting aside LINQ to SQL in favor of its grumpy old uncle Entity Framework made me take a serious look at the EF for my latest big project. Luckily, it hasn't had too much of a learning curve, but I haven't gotten to the hard stuff yet either. I'll need to pick up a book on it at some point, but I'm still thrashing my way through WPF at this time and don't need another book to read right now.

One thing that frustrated the crap out of us here last week was not being able to go from a child entity to a parent entity easily. That is, until I learned the trick. And there's always a trick, isn't there.

Say you have a collection of warehouses, and each warehouse has a collection of doors. Given a door id (GUID), get the warehouse it is at. The WarehouseID is foreign keyed to the Door table.

You would think (based on LINQ to SQL), that you could go Door.WarehouseID or at the very least Door.Warehouse.WarehouseID... but alas, no can do. EF hides the relationship through an object called an Entity Key. In my brain, this was a little ridiculous, since I knew what my key was, just give it to me.

But I guess this is why I don't design frameworks for a living. The Entity Key is a dictionary collection, of all the keys that make up the relationship. Thus, if you have more than one column in the key, the EntityKEy collection contains both keys, but you can access it to use those values with a little care.

By adding a property to the Door object in a partial class, you can access the dictionary to extract the value. If you have multiple values in your key, be careful to index the Key properly.



public Guid WarehouseID
{
get
{
return new Guid(WarehouseReference.EntityKey.EntityKeyValues[0].Value.ToString());
}
set
{
WarehouseReference.EntityKey = new EntityKey("ContextName.Warehouse", "WarehouseID", value);
}
}

Tuesday, November 4, 2008

Back from the Great Beyond

Ok, I haven't been dead, I've just been time travelling. No, really. I jumped back in time to work on a big client project in Visual Studio 2005 using the Microsoft CAB and MVC pattern. While I did learn quite a bit about the client's business (which is not a bad thing), it wasn't technically challenging. In fact I slowed down on my reading of technical stuff, spent more of my free time (ok commute time), reading for fun, and writing for fun. Yes, writing can be fun too.

I also spent a lot more of my nights and weekends doing work for the project, which meant less tech reading as well. A lot of the changes I needed to make to the client systems in preparation for the rollout had to be done off hours to minimize impact on the user.

Sure, I learned a few tricks and tips in the last couple of months. I got very familiar with the Infragistics NetAdvantage Product Set, including the UltraWinGrid (very nice) and UltraWinSchedule (a little buggy in the version I had). But for the most part, I've been just churning code, doing database work, and doing rollouts.

That project is just about over now, with final rollout scheduled for this Saturday. My new project is all new technology, and I'm jumping in with both feet. I've spent the last few days watching videos, reading blogs, and running sample code.

What's got my attention, you ask? Windows Azure. Windows .NET Services. Microsoft SQL Data Services. WPF. Silverlight2. LiveMesh. Yep, 4 of those 6 things are still in CTP, and I'm jumping in with both feet. I'm not just going to be on the bleeding edge, I'm fully stabbed in the chest, in a full out ebola like blood letting.

We'll see how I feel about it in a couple of months, but right now, I'm really excited. My night stand reading is piling up with tech books and blogs. I'm not sure how much I'll be able to post, but I'll try to post hints, tips and other cool things to look at as I learn.

By the way, the current book I'm reading is Pro WPF in C# 2008. I'm just a chapter or so into it, but WPF is something I need to know inside and out for this project, so expect a few blogs on that.