Any application ever build have an architect designing it. That architect could be a software architect, lead developer or just a regular code monkey and probably all of them at some point or the other. The point is that someone has made a lot of important decisions on how an application is structured. For me, that’s the best part of the project life cycle – the challenge to make qualified decisions that has to withstand time and changes.

For a regular component library, business- or data logic layer, service endpoints etc. this is very challenging but there is a lot of written material you can look to for help until you get it down. Dare I mention design patterns? In my experience, the initial design and architectural phase of a component or class library project is highly prioritized by managers and project leads. That’s good, because if the overall architecture is wrong, the project will ultimately fail.

ASP.NET web projects are a little different when it comes to architecture. First of all, the initial architecture doesn’t get as highly prioritized as it needs. Secondly, there are very different rules that apply to web projects. They are hard to impossible to unit test without spending and insanely amount of time writing click-test scripts etc. The output also varies from browser to browser, which can cause trouble for even the most experienced web developer and ultimately prolong the development.

When the ASP.NET developers start hammering on their keyboards things start to get complicated again. For every little feature there has to be made decisions to optimize the implementation. If you are adding a business object to your business layer it is much simpler. You “just” need to create a class derived from your business base class, add some properties and persist its state to the data base. I’m simplifying this but a lot of times that’s all you need to do if you have a decent base class. That’s because the architecture was done up front.

A new feature to a web project on the other hand, needs much more architecting by the individual developer. Will you use user controls, server controls and AJAX? If you use AJAX, will it be most optimal to use Prototype with an HttpHandler, ASP.NET AJAX or client-callbacks? Will you lazy load your page/control and what about caching? Will you store state in ViewState, session or the cache? How will you handle exceptions since you can’t bubble them up the stack and what about usability and accessibility? Will you use a Repeater or manually write out HTML to a PlaceHolder and what do you do to mitigate SQL injection and cross site scripting attacks? These decision and many more have to be made for every new feature.

It seems that the ASP.NET architecture is backwards from conventional software architecture. You spend fewer hours up front but for every little feature you need to spend a lot of time architecting. It’s totally opposite from conventional development in that regard and it leaves the decisions in the hand of the developers instead of the architect. The more time you get from management to architect your ASP.NET project, the more control you’ll have over the end result implemented by the developers, but in the end it might just be enough with thorough guidelines and accept that a lot of decisions are left in the hands of the developers.

I’ve done both conventional architecture and ASP.NET architecture over the years and my experience tells me that ASP.NET is more prone to diversity in implementation because of all the decisions that are left with the developers. Maybe it’s just the nature of web development.

I’ve been following the new ASP.NET MVC framework quite close lately because it looks so damn cool. Not only does it make your website testable in a much richer way, but it also adds abstraction between your different UI tiers. It can do these things because it uses a somewhat strict code separation principle like all MVC frameworks do.

So instead of just adding an .aspx page (with its code-behind file auto-inserted by Visual Studio) to your website, the MVC framework wants you to add a model and a controller as well. The .aspx along with the model and controller is highly abstracted so you can replace one of them easily without changing the others. We know this from the class libraries and components we’ve build for many years – something called low coupling.

The divide

Because the MVC framework is a much stricter environment it will have effect on who is going to use it. The professional and hardcore developers will love it for all its advantages, but what about the hobby developers? To say it in another way, if the MVC only attracts the great developers what will happen to the good ones?

The great developers care deeply about abstraction and testability and they will probably use the MVC framework for any new project they start building. The good and hobby developers probably won’t – in fact they might never feel attracted due to the strict nature of the framework. They might think of it as more complex which I would agree with to some extend.

If we for a moment believe that it is what’s going to happen, then we end up with a developer divide in the ASP.NET work force. Some companies hire MVC developers which now only covers a portion of the work force. The other companies who use standard ASP.NET might not be attractive to MVC developers and will only reach the other portion. With the current developer labour shortage where both great and good developers are needed I can foresee trouble.

Dual community

Because the MVC will split the developers in two portions we should expect the same to happen to the ASP.NET community online as well as offline. The MVC developers might stop visiting the standard ASP.NET community websites and vica verca. It is not entirely true because both frameworks use many of the same components such as the provider model etc.

However, the MVC framework doesn’t use the postback model or the page life cycle so a lot of tutorials, examples and other community writing will become uninteresting for MVC developers. My fear is that the result will be a dual community which could hurt everyone because there will be less relevant material available online. Less relevant because the MVC developers will write mostly about MVC stuff and ASP.NET developers about standard ASP.NET stuff and thereby will the amount of written material be divided into two variations that isn’t always directly usable by the other portion of developers.

Since search driven development is so important for the everyday developer, I see this as a serious threat to the community. If the MVC framework can attract non .NET developers to shift to the .NET platform this probably won’t be as serious.

I think it’s great that Microsoft is building an MVC framework and I look forward to exploring it and hopefully build some solutions with it. I just fear it comes at a price and the community will ultimately pay. Time will tell. If you haven't seen it yet, then go watch a video of Scott Guthrie demonstrating the MVC framework.