In my last post about ASP.NET MVC, Jeff Gonzalez referred to WebForms as “Classic ASP.NET”. I had to take notice since when ASP.NET can out, we spoke about “Classic ASP”. This mere reference is interesting.
His comment goes on to talk about how ASP.NET MVC isn’t mature and not as “rich” as WebForms, but it also mentions the risks around using beta software for enterprise software.
My comments around this relate to the risks of using new, unproven, software. SQL Server 2008 is still not widely adopted even though it is fully supported by Microsoft because folks are very leery about upgrading something as critical as a database server. The same with server operating systems. I hoster I like very much, Rackspace, still promotes and sells many, many Windows Server 2003 licenses (including some for my clients).
Software tools, libraries and frameworks are a bit different, however. First, when you have a new project, it is wise to consider what version of libraries will be supported when the new project goes into production. To some extent it pays to attempt to avoid being a version behind even before the software launches. This is the case with ASP.NET for me. I know where this framework is going, and I trust the reliability of the proven ASP.NET pipeline of handlers and modules. I also trust the stability of IIS, on which it runs. The new paradigm is when ASP.NET needs a handler to handle a particular request. This is where the change in development is. For me, this mitigates risk around scalability and robustness because the foundation is already proven by 8 years of production use.
The other risk is around bugs. When your enterprise application goes into production, you want to be able to depend on your chosen libraries. If your test feedback cycle is long and expensive, there is not easy way to accomplish this. If, however, you have test automation, you can have high confidence that the software works as intended every step of the way. Regardless if the libraries in question are from a huge software vender like Microsoft or a single open-source developer, I consider it a must to have high test automation coverage to mitigate not only the risks of local software defects but also those within libraries on which your software depends.
Another consideration about maturity is documentation, and this is nothing to sneeze at. With 6 books on ASP.NET MVC slated to come out this year, the information will be there, but it is not there now, and many teams will need training on how to make pages with the new version of ASP.NET. This is definitely something to consider. Also consider that many projects successfully use log4net, NHibernate, StructureMap, and other open source libraries without full books written on the topic. In these cases, local documentation is sufficient. As always, you have to decide for yourself given immediate constraints.