LA.NET [EN]

Jun 03

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:

MVCWrapper

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.

4 comments so far

  1. Giovanni Bassi
    10:34 pm - 6-3-2008

    Hello Luis,

    They used Abstract Classes for a purpose: to do not create versioning problems on future releases.
    Take a look at Phil Haack”s posts:
    http://haacked.com/archive/2008/02/21/versioning-issues-with-abstract-base-classes-and-interfaces.aspx
    http://haacked.com/archive/2008/02/21/abstract-base-classes-have-versioning-problems-too.aspx
    It makes sense, right?

    Um abraço,
    Giovanni Bassi

  2. luisabreu
    10:52 pm - 6-3-2008

    Yes and no.

    I”m not sure that this model is good. I would prefer interfaces with new functionality being added to a new derived interface.

    Even though versioning might have been the main idea behind this approach, I still think that the biggest advantage is in testing…

    abraços!

  3. Josh
    1:10 am - 6-4-2008

    Another reason for abstract class. Is an interface requires you to override all methods while an abstract class you can choose to just override what you want to mock for unit testing.

    http://undev.spaces.live.com/blog/cns!6526A337A687E45D!214.entry

  4. Chuck Durfee
    6:15 pm - 3-11-2009

    Cache can be instantiated and used in non-Web applications through HttpRuntime.Cache, as discussed by many include Scott Hanselman (http://www.hanselman.com/blog/UsingTheASPNETCacheOutsideOfASPNET.aspx). Hence, no need to wrap it.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>