davidebbo/WebActivator — pull request #4 by sobanieca (2012-12-18 11:27:41+00:00)
Title: Config abstract class introduced

Hello,

I'm sending a pull request. I have made quite big changes so they need community review. My proposition is not to force developers to use attributes, but instead to force them to define classes in App_Start folder that inherit from abstract class Config. This will allow to achieve greater fliexibility, because one will be able not only to perform single startup code for an application but also to attach event handlers (just like an HttpModule does). For this reason abstract class Config contains a following methods:

PreSetup() - executed before Application_Start() (once per App domain)
Setup() - executed after Application_Start() (once per App domain)
AttachEventHandlers() - executed once per HttpApplication instance. Method for attaching events like BeginRequest, EndRequest etc.
Shutdown() - executed at the end of application (once per App domain)

All these methods are virtual, so there is no need to implement all of them. One can just override the method that he wants to use (I suppose that most NuGet packages will override Setup() method). I believe that abstract classes are more object oriented and allow to make unit testing a bit easier - one can just create a test for a single startup task.

Summarizing, in this fork, if someone wants to add a startup task he should create a class that inherits from Config class, say MyStartupTaskConfig and place it inside App_Start folder. This will be quite consistent with current convention that has been introduced in ASP.NET MVC 4.

I have also added virtual property to Config class - Priority. It is enum with following values: {VeryLow, Low, Normal, High, VeryHigh}. I believe that enum values will be better choice than Int32 values for startup config tasks order. The reason for this is because WebActivator is being used by many independent libraries and it will be easier for developers to specify a priority letting them now that their task may run in parallel with other tasks with same priority from different libraries.

Of course everything is backward compatible - attributes are still there. Unit tests and sample web app have proved that nothing has been "destroyed".

I hope that you will accept this pull request and SIGN the assembly (unfortunately applications that I'm developing are signed) so I will be able to use it in my own NuGet package :)

Regards,
Adam Sobaniec