An Architect's look at Microsoft Technologies in the Enterprise

Menu

Month: March 2011

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.

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:

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:

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!

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:

Front-End Layer, responsible to authenticate, authorize and route each requests to a partition server.

Distributed (and replicated) File System (DFS), responsible for storing bits on disk and to replicate it.

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!

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!