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’m a big fan of the System.IO.FileInfo object in .NET because it wraps the System.IO.File object nicely in a strongly typed way. It makes it easier to work with files. The FileInfo class has a method called OpenText that returns a StreamReader instance which can then be read into a string and other things.

If you use the OpenText method read the text of a file, then the easiest way is like so:

FileInfo fi = new FileInfo("C:\\currency.xml");
string content = fi.OpenText().ReadToEnd();

Now the content variable contains the text content of the currency.xml file, but there is a problem with this approach. Because the OpenText method creates a StreamReader instance which we then call the ReadToEnd method on, the StreamReader keeps a lock on the file. The can cause many problems and must be avoided.

Instead you could do like so, which releases the file handle when the StreamReader is disposed:

FileInfo fi = new FileInfo("C:\\currency.xml");
StreamReader reader = fi.OpenText();
string content = reader.ReadToEnd();
reader.Dispose();

This works fine, but we doubled the lines needed to read the text. This might not be an issue, but then we could just as well just use the StreamReader directly without using the FileInfo class like so:

using (StreamReader reader = new StreamReader("C:\\currency.xml"))
{
  string content = reader.ReadToEnd(); 
}

It is much cleaner than using the FileInfo class and the intent is very clear as well.