Entity Framework 4.1 RC: Including Code-First

Microsoft has published the first release candidate of Entity Framework 4.1.  This new release includes the very popular Code First feature, allowing to model your data in the code, without any designer tools.

With this Release Candidate comes a promise:  the final release will come within the next 4 weeks and will be %100 compatible with the current RC.

If you’ve read my blog post about EF POCO capability, you’ve seen that Entity Framework currently lacks support for a clean class model, i.e. a set of classes representing your data but totally freed of dependencies to the Entity Framework (via base classes, attributes, etc.).

With Entity Framework 4.1, this changes.  We can now model classes in a POCO fashion and the Entity Framework will map to them.

You can find a simple walkthrough at this blog post, so I won’t repeat it here.

I’ve just started to toy around with the RC.  So far I find it pretty neat.  The fluent API has a very natural feel for configuring different mapping.

The lack of documentation is quite painful at this point.  But hey!  If you’re an early adopter, you’re used to navigate blog posts talking about outdated versions of the CTP and using a lot of reflection!

A big feature of this RC is the ability to generate the database out of the model.  I found it pretty limited since EF 4.1 doesn’t include any support for ‘migration’, i.e. the capacity of adapting the database following a change in the class model.  Microsoft is working on it though and this should be available in a future release.  I’m not a huge fan of generating a database out of a class model (simply because it’s impractical in any Enterprise).  In order to make it work properly, you would need to decorate your model with attributes from System.ComponentModel.DataAnnotations namespace, otherwise the conventions will null all non-PK/FK columns and assume ‘standard’ string-size (128).  This doesn’t bring a dependency to EF directly, but it does charge your model with distraction, although the added ‘richness’ can then be used for validation.

My next step is to look into mapping inheritance into the data model.

Asynchrony in .NET

Microsoft recently released a whitepaper on the future of Asynchrony in .NET along with a CTP SDK.

This CTP attempts to address one concern:  how to make asynchrony easy in .NET by removing all the friction in code.

In .NET, Asynchrony, so far, as been treated with the pattern BeginXYZ / EndXYZ dynamic duo.  For instance, in the System.Web.UI.Page class, you can either use the synchronous ProcessRequest or the asynchronous pair AsyncPageBeginProcessRequest / AsyncPageEndProcessRequest.

This pattern works.  It does deliver the goods and if you implement it throughout your code, you’ll rip the benefits of scalability (in that your threads won’t be blocked waiting for IO work) given by asynchrony.  This work will also come with a slight side-effect:  your code will be very hard to read and debug.  The reason, and it is very well explained in the whitepaper, is that this pattern disrupt the control flow.

The basic reason is that when you use this pattern, you work with call backs.  Instead of having one method, you have two:  one invoking the asynchronous work, the other one being called back once the asynchronous work is done.

To use an example given in the whitepaper, here is your synchronous code:

public int SumPageSizes(IList<Uri> uris)
{
     int total = 0;

     foreach (var uri in uris)
     {
         statusText.Text = string.Format("Found {0} bytes ...", total);

         var data = new WebClient().DownloadData(uri);
         total += data.Length;
     }
     statusText.Text = string.Format("Found {0} bytes total", total);

     return total;
}

versus the asynchronous version (on download data):

public void SumPageSizesAsync(IList<Uri> uris)
{
     SumPageSizesAsyncHelper(uris.GetEnumerator(), 0);
}

private void SumPageSizesAsyncHelper(IEnumerator<Uri> enumerator, int total)
{
     if (enumerator.MoveNext())
     {
         statusText.Text = string.Format("Found {0} bytes ...", total);

         var client = new WebClient();

         client.DownloadDataCompleted += (sender, e) =>
         {
             SumPageSizesAsyncHelper(enumerator, total + e.Result.Length);
         };
         client.DownloadDataAsync(enumerator.Current);
     }
     else
     {
         statusText.Text = string.Format("Found {0} bytes total", total);
         enumerator.Dispose();
     }
}

Another great example of the complexity emerging from a simply control flow when put in asynchrony is this MSDN article on Asynchronous pages in ASP.NET 2.0:

http://msdn.microsoft.com/en-us/magazine/cc163725.aspx

So basically, the pattern exists but it’s so convoluted that its usage isn’t widespread.  Now what are the consequences?

Well, efficiency mostly.  It means that every time you need to access an external resources (File, DB, Web Service), you use a thread to wait for that resource to come back to you.  You basically burn gas.

Enters the new asynchrony pattern.  Let’s take the previous example (from the whitepaper), with the new async language support:

public async Task<int> SumPageSizesAsync(IList<Uri> uris)
{
     int total = 0;

     foreach (var uri in uris)
     {
         statusText.Text = string.Format("Found {0} bytes ...", total);
         var data = await new WebClient().DownloadDataAsync(uri);
         total += data.Length;
     }
     statusText.Text = string.Format("Found {0} bytes total", total);

     return total;
}

Wow, that looks awfully the same as the synchronous version, doesn’t it?  What are the differences?  Well, they are already highlighted.

The key:  async & await keywords.  Those are new language construct.  Remember .NET 2.0 yield keyword?  Think of it as something similar, because your friendly compiler is going to work as hard with the new keywords!

Basically, it means that this method isn’t just returning the total as it seems to do, it returns a task (a .NET 4.0 class representing an asynchronous piece of work) returning an integer.

The compiler will tear the method apart to basically let the start of the method until the await execute synchronously and the rest as a call back.  Better yet, it does so by capturing the synchronization context of the original thread and execute each bit of the method on that synchronization context.

There is much more to say about what those keywords are doing, but I would just duplicate what is written in the whitepaper.  I just wanted to tease in order to read it, so go on and read it!

Windows Azure Storage Architecture Overview

Interesting article published at the end of last year:

http://blogs.msdn.com/b/windowsazurestorage/archive/2010/12/30/windows-azure-storage-architecture-overview.aspx

The article does a deep dive into the Storage Architecture of Azure.  It’s a shame this feature seems to on ice for Microsoft (by customer demand for sure, since SQL Azure is getting all the fans), since the architecture has a lot of potential in scalability and reliability.

The three main layers are:

  1. Front-End Layer, responsible to authenticate, authorize and route each requests to a partition server.
  2. Partition Layer, responsible to load balance partitions across a server farm.
  3. Distributed (and replicated) File System (DFS), responsible for storing bits on disk and to replicate it.

image

The article goes through a request lifecycle, how failures at different layers are addressed, how Azure Fault & Upgrade domains relate to this architecture and how partitioning is automatically handled.

This gives you a very good overview of Azure Storage behind the scene!

Creating numbered headings or outline numbering

Far from fancy technological questions today…

How do you configure Microsoft Word to assign numbers to your section headers in a hierarchical way, e.g.:

  • Header 1 (1)
  • Header 1 (2)
  • Header 2 (2.1)
  • Header 2 (2.2)
  • Header 3 (2.2.1)

etc.?

Well, maybe you’re in my position and you always had documents configured properly but today you have to configure one yourself.

It turns out it’s far from trivial.  There are no ‘activate hierarchical header numbering’ in Word!

Instead of explaining here, I’ll refer you to the excellent article Shauna Kelly (who seems to be a black belt in template document):

http://www.shaunakelly.com/word/numbering/outlinenumbering.html

The short story is that you have to create a multilevel list, configure it (by default it doesn’t carry its parent sections number and the indentation increases at each level) and associate each level to a header style.  There are bumps along the road on each steps, so be careful!