MEF ,Prism and the Surrounding Confusion!!

While reading up on Prism 4…the integrated Prism which ships in .NET 4.0, i  saw people still wondering on how MEF and Prism compare…are they the same…do they complement….etc etc..Having seen these questions almost 2 years back with Prism(then called the CAG) and MEF were just announced i was surprised the confusion still exists…

Here is how i explained it to myself…hopefully it helps you too!!

The main reason everyone seems to be confused it “they both help create extensible and modular applications”!!!

MEF is primarily an “extensibility” model…it helps you make “extensible” applications by allowing your application to “import” modules dynamically at runtime. For example all you may need to do is drop the dll of your module at a specific folder and it magically becomes a part of your application!!

So it “explicitly” provides “extensibility” because you are purposely extending your application by importing modules into it , and it “implicitly” provides modularity because your application is made up of modules!!!So the MAIN reason you would go for MEF is when you want a modular application with application extensions where the extensions can be added dynamically and at runtime..


Now for Prism..

Prism is a “guidance” on how to make client applications modular. It maintains modularity by keeping all the modules of the app loosely coupled(with no knowledge of each other). The GUI defines regions where the modules are loaded dynamically. The framework provides a publish-subscribe events model via an EventsAggregator which enables the modules to communicate with each other without any tight coupling..

So Prism “Explicitly” provides modularity and implicitly supports Extensibility as a side effect of good modularity:-)

Now with Prism 4.0 we can see examples of using Prism +MEF together which will be the ultimate combination of an extensible and modular application!!

Hope this clears your confusion…it definitely cleared mine!!


Azure Scalability:- Use “Queues” as your bridges..

I feel the importance of Queues as a communication medium between Web and worker roles is quite a bit under-glorified…apart from acting as reliable messengers , if implemented properly Queues pretty much hold the key to your application being Extensible and Scalable

Windows Azure Queue allows decoupling of different parts of a cloud application, enabling cloud applications to be easily built with different technologies and easily scale with traffic needs.

This above definition is full of some very important keywords..decoupling.…different technologies…. scale with traffic needs…all very important to make a scalable and extensible application..

Lets see how Queues help in all these aspects.

1.  Scalability:-

  • Observing the queue length and tuning the number of backend nodes accordingly, applications can effectively scale smoothly accordingly to the amount of traffic. A growing queue length or an almost always zero queue length is an indication of how loaded your worker roles are and you might want to scale them up or down accordingly
  • The use of queues decouples different parts of the application, making it easier to scale different parts of the application independently. This allows the number of web and worker roles to be adjusted independently without affecting the application logic.
  • Separate queues can be used for work items of different priorities and/or different weights, and separate pools of backend servers can process these different queues. In this way, the application can allocate appropriate resources (e.g. in term of the number of servers) in each pool, thereby efficiently use the available resources to meet the traffic needs of different characteristics

  2.     Extensibility:-

  • Different technologies and programming language can be used to implement different parts of the system with maximum flexibility. For example, the component on one side of the queue can be written in .NET framework , and the other component can be written in Python.

3.   Decoupling:-

  • Changes within a component are transparent to the rest of the system. For example, a component can be re-written using a totally different technology or programming language, and the system still works seamlessly without changing the other components, since the components are decoupled using queues.  The old implementation and the new implement can run on different servers at the same time, and process work items off the same queue. All these are transparent to the other components in the application

But to be able to achieve all these benefits you need to make sure your queues are implemented in the most optimal way . There are a lot of best practices around Queue implementation such as Invisibility Time, Delete queue messages, Worker role instance manipulation etc…more on that some other time…meanwhile if you want more inputs on “Queueing your way to scalability” drop us a a note at

Until then!


Bulb Flash:- Azure Message Queues-Passing objects

Azure queue takes either an array of bytes or a string as an input. While working on a web role- worker role interaction , i needed to pass the entire TableServiceEntity object(basically the Azure table datamodel) to the worker role.

I needed the partition key, the row key as well as some other attributes of the database entity in the worker role to do some processing…the best way out was XML Serialization!!

//serialize the tableserviceentity object in your webrole

Suppose your TableServiceEntity class is called XYZDataModel

//Deserialize it in your worker role

And now you have your XYZDataModel entity recreated in your worker role!!..Hope this helps you..We certainly will try to remember this piece of code!!



Programming Table Storage in Azure…Choosing your Keys!!

Azure holds a lot of promise for applications with

1. Spikes in usage

2. Requirement for low set up cost

3.Huge storage requirements

Out of these 3 major benefits, most applications will exploit the 1st and the 3rd potential of Azure!..While Spikes in Usage is more related to how the application is architected etc(we’ll talk about it in another post), huge storage requirements is a pretty interesting topic…the potential here is enormous..

You want to learn more on Silverlight 4, won’t it be cool if you could just see what articles people have read and which ones they found useful and why?? I am sure it will help you make more out of your time by helping you weed out the “not so useful” articles….but who would take the onus of storing such HUGE data?? Well something like Table Storage in Azure could be the answer to is a scalable, extensible and inexpensive storage medium to store just this type of data…

While just having fun with Azure, we made this small app which allows a user add a weblink onto the Azure table storage…


he can then also search the entire table for weblinks of his interest based on categories..


One can take this forward to search by submitter, or Category+ rating etc etc..

The entire application is uploaded here…its a rough sample (so no commenting etc etc )but it will give you a idea..if you have any issues with it…its!!!

There are lots of samples out there so i don’t want to focus on “how to program” this….i am more interested in the most important aspect of using the Table Storage in Azure….How to select you Keys!!(Partition + Row Key)

Basically your partition key should be the most commonly used filtering criteria for your application….so basically you need to realize the main purpose of the application and in what way it is going to be used, what kind of queries are going to be most frequent…one tip here is that the you should be able to use your partition key in the where clause of almost all your queries..

Lets see what kind of querying makes sense for this simple application

1. Get me all weblinks in CategoryX

2. Get me all weblinks in CategoryX with Rating Y

3. Get me all weblinks submitted by User T

4. Get me all weblinks submitted by User T in Category X

etc, etc

If you notice most querying is going to involve the “Category”, so we should be able to use Category in the where clause!!….so the partition key becomes category!!

You must use Category as a condition in most of your queries


Now for the Row Keythe rule here says that if there are 2 frequently used keys, use the most freq as the partition key and the other one as the Row Key…so if you see the querying, you will be tempted to use the “SubmittedBy” as the row key…but there is a problem…PartitionKey+RowKey should be unique for every row in the table…so if you use SubmittedBy as the Row key, a user will be able to submit a weblink for a category only once…makes no sense!!

For applications such as this…it makes sense to use Guid.NewGuid as the row key to allow multiple entries and still maintain uniqueness…

Like i said, let me know if you want the source code…will be happy to load it somewhere for you!!…Azure table storage has huge potential as long as the keys are selected properly!!!