Building Highly Testable Web Applications With ASP.Net MVC

Web applications are notorious when it comes to testability. The problem is further compounded when applications have a complex user interface. Recently we did an architecture consulting for one of our clients in the financial industry for a web based application which is part of their core product offering. The product is an enterprise solution which supports multiple client configurations. The application is built on classic ASP and COM relying on the main database of the product for storage apart from a centralized file storage system.
One of the key challenges faced by the application was testability. With code and markup being tightly coupled, what some ASP.Net developers derisively call as spaghetti code, it was close to impossible to write functional unit test cases for the application. The most likely solution was migration of the application to ASP.Net with clear separation of code from markup. However past experience told us that this works well only if the pages are fairly simple and complex pages often resulted in bloated code behind files which are hard to test and maintain. This lead us to consider ASP.Net MVC as a suitable solution approach.
In the world of web applications adoption of MVC pattern opens up possibilities like never before. It is common practice to have minimal code in the code behind and move the operation logic in its entirety to controllers with the ability to support multiple views. This enables clear separation of view from the presentation logic and thereby creating opportunities for testing the application which hitherto didn’t exist. Typically a test double is hooked up with the controllers and one could proceed with testing well before the look and feel of the user interface gets finalized.
The folks at Microsoft foresaw this and introduced the ASP.Net MVC framework as an alternative approach to the traditional web forms based development model. ASP.Net MVC paves way for building applications which follow test driven development (TDD). Controllers could be unit tested outside the ASP.Net process itself and any unit testing framework could be leveraged for this purpose.
There are other benefits as well such as ASP.Net MVC comes with a powerful URL routing mechanism. No longer are requests made to specific web pages with an extension. For example, the URL MyServer.com/Orders/Status/1234 would replace MyServer.com/Orders/ Status.aspx?id =1234. Note the difference: ASP.Net MVC URLs follows a more RESTful style compared to the old web forms model.
Few points that need to be kept in mind before making key decisions:
1) ASP.Net MVC ushers in a radical change in the underlying framework. Pages no longer receive requests; instead requests are routed to controller classes which manage the views. It is quite possible to support other higher level frameworks on top of MVC, for instance building a composite user interface with Composite Web application block with an MVC approach is possible.
2) ASP.Net MVC as a framework addresses building user interfaces in a fundamentally different way. However when it comes to strategies for authentication, session management, use of providers, authorization, localization, caching etc there are no changes. An interesting implication is parts of an application rebuilt with ASP.Net MVC can coexist with rest of the application still using the web form post back model making a strong case for migration.
3) ASP.Net MVC introduces more elements in the projects than one would normally have. It is typical for a complex web page to be broken into multiple views and controllers. In a sense, few tightly coupled larger components are broken up into several loosely coupled parts. Sometimes this is viewed as a disadvantage.
4) One does really need to think in terms of MVC to realize the benefits, and better design skills can make a telling difference. ASP.Net MVC applications are typically high on design.

Since the key issues of our client revolved around testability and a maintainable codebase, ASP.Net MVC seemed to be a natural fit. However there were some concerns around ASP.Net MVC being a brand new framework in its beta version (a release candidate is available now). However such fears were unfounded for the following reasons:
1) ASP.Net MVC though it was a beta version came with an explicit go live license from Microsoft. Microsoft had experimented with several preview editions for almost a year, before deciding the bits for the beta edition. A "go live" license ensured backward compatibility in future versions.
2) Building web applications on MVC is an established norm, though it is new to ASP.Net. Frameworks like Ruby on Rails rely heavily on the MVC pattern. Even before ASP.Net MVC , third party solutions were available for building ASP.Net applications using MVC pattern. More notable among them is Monorail framework of Castle project. ASP.Net MVC works well with these third party solutions. For example ASP.Net MVC optionally lets users plug in MonoRail’s view engine.

Apart from suggesting the ASP.Net MVC approach, recommendations were made around strategies for session management, caching, storage, load balancing, use of third party controls & themes. All considerations applicable to ASP.Net applications hold good for applications built on ASP.Net MVC.
As with any new framework one can expect some churn, however the most recent cut of ASP.Net MVC is quite stable and without doubt a whole new way for building great web applications.

Strategy for building modern UX on WPF

Recently we were on an UX consulting assignment with a financial services provider in the east coast of the United States. The company had an application suite that was several releases old with monolithic user interfaces which needed whole lot of rethinking when it came to good design.
The applications had thick and thin clients with related functionality built using Delphi and VC++. ActiveX controls were used to provide rich functionality inside thin clients.
The company was facing problems in key areas:
Upgradeability - This was a major challenge with clients using different versions of the applications and turned into a nightmare when considering client specific customizations. It’s not uncommon for an upgrade to bring down the entire system.
Manageability – Custom formats, policies and use of certain terminologies made the applications very hard to manage. There was a sore need for standardization across the system.
Interfacing - Use of several proprietary protocols for communication was a priority issue. It was not an easy task for a third party to sync up with the applications.
Reuse – This was a major pain point with duplication of modules and controls across product lines. The sheer vastness of the codebase aggravated the problem. A careful look leaves one with an impression that things could be lot simpler.
Due to budget concerns, there was a crying need to get out a minimal set of functionality that would make the necessary difference. Hence it was out of question to make server side changes or modify the existing communication strategies.
After some discussions we were able to buy agreement across all quarters to base the entire application suite on thick clients and build them using WPF. XBAPs (WPF application hosted inside a browser window) were considered but sidelined, as the limitations weighed down on everybody.
Fortunately, we had a functional consultant working with us, who made life easier by addressing the need for reuse in the user interface and raising a clarion call for standardization.
On the technical side, couple of things were evident. There was a huge potential for identifying common behavior across applications and putting them into well defined silos. There was potential to turn the monolithic user interface screens into composite ones through use of frameworks such as composite WPF (aka Prism). However considering the limited budget and the significant analysis effort that is a norm for turning a massive monolithic application into a composite one this idea was dropped. However we decided to take forward the patterns & techniques that inspire composite applications such as MVC, dependency injection etc in principle into the proposed solution.
We spent time identifying the “commonality” in UI behavior across several applications. We could notice exceptions but there was a significant amount of functionality which could be considered identical/related if only we could externalize the “difference”. For example the data load operation would be identical if we could account for the difference in terms of target controls, and the query used to pull the data. Same with the lookup operation. We had our laundry list ready.
We went one step further with the MVC pattern by suggesting a generic controller for all common operations apart from application specific controllers. The generic controller could be driven by rules that could be externalized. This would significantly reduce the client’s code base and vastly improve maintainability of the system. We recommended ClickOnce as the distribution strategy for solving the problems associated with upgradeability. Initially we were toying with idea of keeping the XAML (a language for defining the user interface in WPF) loose by bringing it into context only during runtime. This idea had to be dropped as it addressed the distribution problem which was not a high priority thing for our client.
After that it was more of identifying “modules” for various elements in the presentation layer architecture. We considered using Enterprise Library for the infrastructure part (logging, caching, exception handling etc). Finally we identified a layer for interfacing with the application suite’s core services and a library for defining common types.
A sample architecture diagram below: