Meet my new ASP.NET MVC Extension - System.Web.Mvc-Kazi Manzur Rashid

After hearing Phil Haack and Scott Hanselman in their latest podcast and PDC session I decided to give a good look at the MvcTrubine project in this weekend. I totally agree the intend of this project, let your favorite IoC to rule everywhere, but I do not think it has been implemented in the correct way. There are three important design flaws that I found in MvcTurbine: Generic Component Registration API Rather than allowing you to use your preferred IoC registration features, it prefers to use its own generic syntax for component registration, which is simply wrong. In real application, we need more support from our IoC such as lifetime management, auto wiring, modularity like (Ninject/Autfac Modules, StructureMap Registry) etc. In case of this generic API we have to throw away the features of these IoCs. Missing Common Service Locator I think the Common Service Locator(CSL) has become the standard to abstract the underlying IoC from your application code and all the popular IoCs in .NET world has an adapter for CSL. But rather than using/extending it, it has its own version of service locator. Limited support for Action Filter injection It uses a host kinda Attribute to inject the dependencies into the actual action filter attribute and this host is not capable of passing the attribute specific values to the actual attribute and even if this feature is implemented in the future it will be based upon the string based property name which would work on top of reflection. Now, lets see how my new extension solves the above issues and how easily you can start plugging it in your application. First lets take a quick look of the project structure of this extension.