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.

ISV Wish List

In the past couple of months we have been working with several ISVs to help them modernize their existing solutions/re-platform the existing application, and after some time a common patter start to emerge across all the ISV requirements - a ISV wish list if you will, which would like to summarize as:

a. Rich metadata driven extensible interface
b. Flexible and highly configurable business processes
c. Support for multiple back ends

In case of a and b (above): ISVs usually have their own professional service group that does the deployment for a new client, traditionally for each customization required by the new client the professional service group would custom develop it, however these ISVs going forward want to leverage a metadata driven approach whereby the UI and validation is dynamically created.

Up until now we have had to custom build many of these capabilities, however now with .NET 3.x several of these challenges can be met using the out of the box capabilities:

a. Rich metadata driven interface : WPF with XAML based declarative approach combined with loose XAML, the new data binding and data templatization model works extremely well for metadata driven solutions, additionally Prism (now WPF composite framework) can be used as the composite application framework container for building a thick client WPF application.

b. Flexible and highly configurable business processes: One stop solution, Windows Workflow Foundation (WF) in .NET 3.x. WF can be used to easily model complex business processes instead of writing large amount of code. Additionally we can leverage XAML activation - whereby the WF can be dynamically build and executed (i.e. dynamically compiled), this provides professional service teams with incredible flexibility to tailor/configure the business process for a given client.

c. Support for multiple back ends: Microsoft Entity Framework currently in CTP provides an entity modeling capability (ORM tool) that abstracts away the underlying DB product. All CRUD operations are performed on the entity data model and the entity framework can translate the CRUD operations to the specifics of the respective DB vendors. Additionally Entity Frameworks works nicely with WCF, all the classes that are generated behind the scene when you create the entity models are created with WCF serialization in mind.

Microsoft also informs us that they too see many ISVs having the same "wish list" and its expected that .NET 4.0 will support more of these capabilities natively.

Technologies that have gone “Cold”

Couple of day’s back we were in technology discussion with a client to discuss the the implementation technology of their product. They were primarily a Cold Fusion shop and we were recommending them to implement the new product on the .NET framework via ASP.NET.

Since we have access to several Microsoft resources, had posted the question to some of the architects in Microsoft if they had any material on Cold Fusion vs. ASP.NET, interestingly couldn’t find an MS architect who was up-to date on the Cold Fusion compete scenario. That’s odd if you think about it cause most of the client facing MS folks walk around carrying MS Tech vs. X technology “battle-cards” around with them and are ready to pounce on the topic. Apparently it seems that these days Cold Fusion is not on Microsoft’s compete radar, hmm…how important is a fact like that? Note that that’s not to say Microsoft doesn’t compete with Adobe. Interestingly other than Microsoft the only other company which has the broadest vision on Rich vs. Reach software delivery is Adobe. In case of MS the Rich vs. Reach extends from WPF->Silver Light->AJAX.NET Asp.NET, in case of Adobe its Flash->Cold Fusion. However on the pure web technology Cold Fusion doesn’t seem to be on MS radar – from what we have seen the other technologies that are on MS radar on the pure web technologies include PHP and Rails (it seems that even JSP has started moving out on the outer periphery of MS radar). From what we gather, the last time Cold Fusion was on MS compete radar was 2004-2005.

Microsoft has just one primary goal - to ensure that Windows is the platform of choice, and they invest huge amount of money into doing comparative analysis on other competing platforms and technologies and are quick to either adopt the new trends or via their internal R&D engine stay ahead of the curve. The compete documents from MS provide insightful cases when MS technologies are better than other etc. In many ways looking at MS radar for technology comparison is like referring to the reports of some of the IT industry analysts like Gartner/IDC/Forrester etc ie instead of spending a lot of our time into investigating the right technologies we can leverage the R&D effort done by someone else. But still, how important to select from a product that’s on Microsofts compete radar? To put it in a different way - imagine your going to direct a movie and you have chosen the lead actor because you have worked with him in the past and he is a friendly guy..however the paparazzi doesn’t care about him and don’t even want to take his pictures… he is just not on the paparazzis radar. Would you still go ahead and direct the move with the same cast? :)

Jokes apart selecting the right platform is a critical first step. We might sometimes be religious of our preferred technologies but at the end of the day the technology you select should be able to give you the best ROI on your investments and a faster time to market. Cold Fusion (CF) by the way is a great technology, several years back it was a very compelling product and was light years ahead of other vendors particularly in terms of productivity (CF abstract a lot of the technical details away from developers). Productivity still continues to be the #1 reason most companies choose CF. But other vendors have caught on productivity side, ASP.NET with Visual Studio.NET and AJAX.NET offer the same level of productivity. However the .NET platform has much more to offer. In many way it does not abstract the details from the developers so there might be a more steeper learning curve, however abstracting too many things is also not a good thing. I still remember the time I was coding in VB (classic VB ie not VB.NET) – VB was a high productive environment that was extremely productive but the moment you had do to something out of the ordinary/required more performance/threading etc you wished you had developed the product in VC++ - i.e. productivity alone should not determine the selection of a technology unless productivity itself is the primary goal (as in case of most departmental level IT projects). Given this clients solution was to be hosted on the internet performance was a key driver for the selection of the technology ie higher performance implies running more on less hardware -> reduce the operational cost, this is where ASP.NET had a clear advantage over CF also since the hardware they already had were Windows based no additional software cost had to be incurred when running ASP.NET however in case of CF they had to purchase the Cold Fusion Application Server. This along with other factors made ASP.NET a more compelling choice.

If you were to build a web application and had to choose a web technology keeping in mind good balance of performance, ROI, productivity etc what technology would you adopt? And would you keep the paparazzi in mind when selecting the technology :)?

Sun in a language soup

For over a decade Sun has been branding Java as the programming language of choice and building new capabilities around the Java framework, interestingly their approach has been to position the language (Java) along with the framework (Java Enterprise Edition, Java Standard Edition etc). Now Sun is contemplating something the .NET framework had since its inception - support for multiple languages. With languages such as Ruby gaining significant adoption by the developer community neither Microsoft or Sun could back away from adopting Ruby – for Microsoft the implementation of another language like Ruby (IronRuby in this case) would be seamless since they would primarily have to make their implementation of ruby Common Language Infrastructure (CLI) compliant. From a technical perspective Sun would not have a significant challenge implementing Ruby (ie the Da Vinci Machine Project) but what would be the message they are sending to the developer community? Will they reposition the JVM? Will it be rebranded? What will happen to all those acronyms in the Java community (JSP, JSF, JNI, JNDI, EJB etc - and 100s of other popular acronyms prefixed with the 'J' moniker), for that matter you cant call it the Java community can you ? J . Wow think about it a community focusing on a platform unified by a single language – now possibly repositioning the framework in another language(s). Chaos.

Should be interesting to see how Sun and the community pulls it off.