asp.netasp.net-mvcwcsf

ASP.NET MVC vs. Web client software factory (WCSF)


I have recently been doing a bit of investigation into the different types of Model View architectures, and need to decide which one to pursue for future in-house development. As I'm currently working in a Microsoft shop that has ASP.NET skills, it seems my options are between ASP.NET MVC and WCSF (Monorail is probably out of the as it wouldn't be supported by Microsoft).

After reading the ASP.NET MVC framework, using the WCSF as a yardstick, I picked up the following points:

What are some of the other considerations?
What have I misunderstood?
Is there anybody out there who has used both frameworks and has advice either way?


Solution

  • ASP.NET MVC cannot use web controls that rely on postbacks, whereas WCSF can.

    You should think of WCSF as guidance about how to use the existing WebForms infrastructure, especially introducing Model-View-Presenter to help enforce separation of concerns. It also increases the testability of the resulting code.

    You have more control over the urls in an ASP.NET MVC site as opposed to a WCSF site.

    If you can target 3.5 SP1, you can use the new Routing system with a traditional WebForms site. Routing is not limited to MVC. For example, take a look at Dynamic Data (which also ships in 3.5 SP1).

    An ASP.NET MVC site will probably be easier to test than an equivalent WCSF version.

    This is true because it uses the new abstractions classes for HttpContext, HttpRequest, HttpResponse, etc. There's nothing inherently more testable about the MVC pattern than the MVP pattern. They're both instances of "Separated Presentation", and both increase testability.

    It seems that the WCSF still uses the code behind to control UI events under some circumstances, but ASP.NET doesn't allow this.

    In Model-View-Presenter, since the outside world interacts with views (i.e., the URL points to the view), the views will naturally be responding to these events. They should be as simple as possible, either by calling the presenter or by offering events that the presenter can subscribe to.

    Model-View-Controller overcomes this limitation by having the outside world interact with controllers. This means your views can be a lot "dumber" about non-presentation things.

    As for which you should use, I think the answer comes down to which one best suits your project goals. Sometimes WebForms and the rich third party control vendor availability will be preferable, and in some cases, raw simplicity and fine-grained HTML control will favor MVC.