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.

Comments


Comments are closed