Yesterday I’ve started looking at the new MVC platform. After looking at the MVC project, I’ve decided to take a look at the System.Web.Abstractions. In this dll you’ll find several wrappers of the objects you normally use on a Web Forms ASP.NET application. The next figure shows some of them:
If you end up using the new routing assembly, you’ll end up using these classes. Notice like this assembly adds 2 classes for “each wrapped” class…for instance, the HttpSessionStateBase class defines an API and just implements all members by throwing a NotImplementedException. These are the general classes that are used by the rest of the MVC platform.
Then there are the XXXWrapper classes that extend the XXXBase classes and are responsible for encapsulating the ASP.NET traditional classes (as you might expect, the implementation of the XXXWrapper methods consists on delegating all the work to an internal field that points to the associated ASP.NET class).
I’m assuming that one of the main reasons that le to the introduction of these abstractions is testing. Since the rest of the API uses the XXXBase classes, you can simply create your own stubs or mocks of these classes and use them in your tests. I’m not sure if using interfaces wouldn’t have been better, but at least now you can easilly mock these ASP.NET intrinsic objects.
It looks like there are still some rough edges though…for instance, there’s an HttpContextWrapper2 class which doesn’t seem to do anything usefull. Another thing that is interesting is that the Cache object isn’t wrapped! So, you have all the other main classes wrapped (event the HttpPostedFile class is wrapped), but the Cache property still delegates to the System.Web.Cache object. I’m supposing that this means that you won’t be able to mock the Cache object…maybe someone forgot to wrap this class?
So, now that I’ve already looked at the System.Web.Abstractions assembly, it’s time to move on and start looking at the routing assembly.