You’ve probably tried it a hundred times before. You start a web project and when you are finished the code is robust, simple and down right beautiful to look at. Then as times go you add more and more features on top of the original code base and it starts to become fragile, complex and ugly. This might be because customers want certain new features or you customize parts of the system for a particular customer.

The excellent architecture and coding standards might get lost over time caused by this growth and customization. The issue is that the original code base wasn’t prepared for those kinds of changes, add-ons and customizations. So how do you prepare your project from a potential future growth without spending too much time on it up front?

Expose events

A very easy way to prepare for future changes is to fire a lot of events. If your business objects have a Save() method, then it will be beneficial to add two events – BeforeSaving and Saved. That way, any future add-on can subscribe to those events and change whatever it need too. This works well for customizations and extensions. See how to create safe events in C#.

Modulize

ASP.NET 2.0 is very easy to modulize because of the many build-in providers and the open provider model. HttpModules and HttpHandlers are also a great way of modulizing an ASP.NET application. By using these features from the beginning you will find it much easier to swap entire parts of the system with new ones.

The HttpModules and handlers are a great way to extend an application with very little effort and a lot can be done pretty much plug ‘n play.

Extension model

If you expect that you or a third-party need to extend your application, then you can build an extension model which is very simple and easy in ASP.NET. If you have an extension model from the beginning of the project you’ll probably find that a lot of your build-in features will be much easier to add as an extension instead of building it directly into the core.

An extension model makes most sense if you have exposed a lot of events because then you have more options and power for the extensions. See here how you build a very simple extension model in ASP.NET.

Prepare for localization

When your application is finished and delivered, the clients ask you to create a Spanish version as well. I’ve had that request quite a few times over the years and if you didn’t prepare your website for localization it becomes a huge task. However, this is very easy to prepare for localization.

All static pieces of text – menu items, help texts, buttons, descriptions etc. – have to be put in a resource file (.resx) and it has to be done from the very beginning. It is very difficult to find all strings and put them in a resource file later.

Use multiple tiers

The rule-of-thumb that I use myself is to build my ASP.NET applications with the minimum of two tiers. The website itself and a business logic and/or data tier. Even the smallest web application will grow over time and it is absolutely essential that all the logic and data access code is kept separate from the website. So, always start with a minimum of two tiers even for your mother’s family photo site. The next thing you know is that she asks you to add a forum and diary and you know you can’t say no to your mother. With multiple tiers you also gain the benefit of swapping individual components easily. Then you can change the data tier to use a database instead of XML files without changing anything else.

I’ve hooked a health provider up in my web.config to send me all unhandled exceptions by e-mail. See here how to do that – you just have to put some lines in the web.config. Well, I get all sorts of different exceptions but one I get more than 20 times a day. It’s actually rear that I get anything else than this one particular unhandled exception.

It looks like this:

Exception type: System.ArgumentException
Exception message: Invalid postback or callback argument. Event validation is enabled using <pages enableEventValidation="true"/> in configuration or <%@ Page EnableEventValidation="true" %> in a page.  For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them.  If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.

Am I an idiot? 

Now you might think that I’m an idiot that I didn’t do anything about it months ago, but hold on a minute. It says that a postback is invalid because event validation is turned on. It’s turned on by default in ASP.NET so that’s no big surprise. No my dear reader, this is not an error I would like to remove by disabling the event validation, because this error is in fact caused by spam bots trying to spam my comments.

They all fail in doing so, because event validation is enabled and thus throwing this exception every time they try. Did I mention to say that event validation is turned on by default and is a native feature of ASP.NET? That means that all ASP.NET application has a natural spam bot protection system build right into it by default. How cool is that?

Maybe this example will convince those of you who didn’t believe me in the last post I did about ASP.NET security and unnecessary CAPTCHAS.

Update 30 minutes later: I've just received 25 more mails in half an hour. Maybe the bots read my post and didn't believe me either.