Ruchit Surati's blog

ASP.Net has come a long way and it is by far the most widely accepted development platform (no offense to php, you have your own place..). I have been using it since long and I just love it. This post is about my best practices while working on an ASP.Net project. Web applications are more performance conscious compared to a native windows client app. You need to take care of many aspects before you actually call it a performing production-grade web-application. Here, I have published a non-exhaustive set of my best practices.

Create a common base page for all your asp.net pages. This page will derive from System.Web.UI.Page and you may put this under YourApp.Web.UI custom namespace. Let all your asp.net pages derive from YourApp.Web.UI.PageBase class. This can reduce a lot of pain when it comes to changing a common behavior or functional aspects across all pages in your application. Like exposing common properties and methods that are used across all the pages.

public class PageBase : System.Web.UI.Page
{
    public PageBase()
    {
        this.Load += new EventHandler(PageBase_Load);
    }

    protected string LoggedInUserName {get;private set;}

    void PageBase_Load(object sender, EventArgs e)
    {
        //Set the LoggedInUserName here, that all pages can access.
    }
}

Use Application_OnError handler to gracefully handle any orphan exceptions. In medium to large size projects, you will have many developers working on the same project, and as a team-lead or module-lead, you are not going to have the scope to check if all developers are dealing with exceptions meticulously. The uncaught orphan exceptions cause the Yellow Screen of death, crash your application and client will see all the things that he or she should not see. Use Application_OnError event within the global.asax where all those nasty unattended exceptions will land up. From here, you can log the exception and notify respective authorities about the error. This will also help you trace back to the piece of code that caused this. You can makr the exception as Handled and show a standard error page to the client telling him – “something went wrong, we will fix it soon. Click here to continue” or something like that that does not ruin the reputation of your application.

Use MembershipProvider and RoleProvider. And Never use inbuilt ProfileProvider – Many developers are totally ignorant about the using the providers that shipped with ASP.Net 2.0. We use them heavily and it takes care of our entire user and roles management mechanism leaving us with more time to focus on the actual application. I recommend not to use the inbuilt ProfileProvider since I do not like the way they store the information (They store everything in plain strings.). This could slow down the performance of your application when you have large number of users. We have written our own custom MembershipProvider and RoleProvider and they just work great.

Use Firebug for client-side debugging. In web development, the tools that you use for development also make a great difference. The rendered mark-up is loaded on the client-side browser where you need to inspect the elements in the DOM and its attributes. Firebug is a boon to web-developers. It knows what you need before you ask. Les you inspect an element with all details that you may ever want to know. Firebug also has YSlow extension which can evaluate the performance-rank of your web-page and advise you on how to improve it.

Use jQuery for client-scripting. jQuery is one of the most essential part of any web application, be it any platform. It has changed the way we script for clients. It has established a standard for client scripting. I have to make sure in any web application project that I work on, I must have at least one cool jQuery ninja programmer within the team. Try it and you will understand what you have been missing till date.

Never store User Authentication information in session or do not use sessions to judge if user is logged on. Every asp.net request carries an HttpCookie for authentication and if you are using FormsAuthentication,you will find all authentication information within the Page object itself. Store only minimum necessary information in sessions.

Disable ViewState where you dont need it. In a page if the UIobject does not need to retain the state across post-backs, just disable the viewstate for the object by setting EnableViewState property to false. At times you may want to disable the viewstate for an entire page. You will soon figure out the page loading faster consuming less bytes of data to transport.

Never ever Deploy asp.net application under debug configuration on production. To me this is a crime. You can never ever deploy a build with debug symbols or config. This is valid for any sort of .Net project whose end-output is a .Net assembly. SottGu has written a nice post on this as to why you should not do this.

User Web Deployment projects. I love simple and compact things. Web Deployment project can compile and merge all your code-behind classes and the classes in app_code into one single project output assembly which you just need to put in the bin directory of deployment. It can transform web.config sections and replace with production server settings during post compilation phase. I have seen projects with 200 pages and their individual assemblies being deployed in bin which means you have a big assembly mess in the bin directory. How about summing them all up in single assembly ? Web deployment projects is just worth for this single feature.

Use Cookie-less domains to serve static resources like images, scripts, styles etc. Each client request brings along a whole bunch of cookies, that you do not need while serving pictures or scripts from server. So host those resources on a cookie-less domain. We have a sub-domain setup to serve cookie-less resources. So we host all our images and scripts on the sub-domain. and from the primary application we just point the resource by its url on the sub-domain. We make sure sub-domain remains cookie-free by not serving any dynamic script on that domain or by creating any asp.net or php sessions. If you dont write cookies from domain, the domain will be cookie-less.

Minify scripts, stylesheets and HTML responses from the server. Markups and scripts are meant for browser engine and they never need to be in readable format post-production. Removing unnecessary line-breaks and white-spaces can improve the time-to-load and bandwidth optimization.

These are the few important things, that I must do in any web application. I am sure you would have your own tricks of the trade that others can benefit from. Please feel free to throw in your ideas and techniques for writing well-performing asp.net applications, in comments to this post.

Posted By: Ruchit in Blog, Programming, Web Development
Tags:

0