Archive | Application Architecture RSS for this section

What makes a good ASP.NET application? Vol. I

I’ve been thinking on this topic ever since I started developing ASP.NET web applications. I’d like to share what I’ve learned in a series of blog posts, and, as you might suspect, this one would be the first of them.

I must warn everybody that this is my humble opinion, and nothing more, so there could be serious errors or mistakes in it, so read it with care. I’ll gladly accept any critics or whatever else, feel free to post it, or mail it to me.

In this first post, I’d like to share my thoughts about an approach, which I would call a dynamic and extensible web site.

I like to build up a website that could become anything from a day to the other. And ASP.NET gives us the opportunity to do so, but we have to consider it in the earliest stage of development. Think about this blog of mine. It’s a rather dynamic thing, anyone can customize it as much as he/she wants, so statistically speaking, there could be hardly two same appearances. But with ASP.NET, we could accomplish even more dynamic solutions. Maybe mine is a rather hardcore opinion, but for example, I always evade the using of the SiteMap and its related tools, just because it lets you specify only one possible sitemap. I prefer to bind my menu controls to XML data sources, on for each role, and never hard code anything in a .aspx file.

An .aspx file, in my opinion, is only a placeholder for possible data. You can specify almost everything outside of it, and then link it with the page. When you have repeating elements on a site, you can wrap them up in a master page. When you have standard style attributes, you can specify them in a CSS file. For non-standard attributes, there are the .skin files for you, so you can (and should) omit any style- or appearance-related information from your .aspx file. Even better, you can redesign the whole appearance of your site with just one click, even from code, by leveraging the Themes feature.

You can omit even the text from them, using resource files, both local and global. A further benefit of these files is that you can give them to a person with absolutely no programming knowledge to translate it into a different language.

This approach is available for controls such as a shopping-cart overview, by using.ascx files, also known as User Controls. But they are too static for me too. I prefer to use them if I need a custom set of controls only in a single site. Luckily, we can create custom server controls, to use our custom controls in multiple sites, just like for example, the Ajax Control Toolkit.

This approach’s serious drawback is its main advantage as well, namely the fragmented layout. But when you want to modify a single menu item, or align one property of a list, refresh the text of your site, or just fix a spelling error, you don’t have to redeploy or reset your application; just modify the related XML, CSS, etc. file.

When you work with .config files, you can catch the trace of this approach. After all, a .config file is the collection of an application’s related properties, available for the whole application in one place. I think we should follow this method to build up the whole of our web sites in ASP.NET.