With this little article I don't want to enumerate the common Best Practices in C# (there are so many articles and blog entries about it, and most of them are really good). I don't want to discuss about using StringBuilder instead of concatenating strings, Arrays vs ArrayLists and so on, I want to share with you some tips I'd learn in my short but intensive experience developing ASP.NET applications.

• All C# Best Practices are valid for ASP.NET, use them.

I don't know why but I'd seen in several projects all pieces are really good except the user interface layer. The data access layer is always the best, with all OOP standards and best practices applied there, also happens with the business components, the horizontal components, the architecture.... What happens with user interface? Why we code ASP.NET pages in a different way? I know this is the most difficult layer for programmers, because you have to make a windows application in a web environment (bad design), using JavaScript to avoid traffic, showing and hiding controls depending on user roles, but this is not an excuse. I'd seen several times string concatenating in ASP.NET pages to build a script function, but never (or almost never) had seen it to build a dynamic query in the data access layer. Why?

• Pages are also Objects.

Everything in .NET is an Object, but most of the code-behind classes I'd ever seen are poor designed. Thinking on ASP.NET pages like objects reduce requirements changes development effort, bug fixing and refactoring. Think you have a class that always invoke some methods from another class in the same order (this is the ASP.NET life cycle and the invoking class is the CLR) and, depending on user actions, one or more methods can be invoked in the middle of this sequence. You know exactly when each method will be invoked, so developing ASP.NET pages shouldn't be so difficult.

• Properties, you can use them.

I know all of you had used properties in almost 100% of the classes you had developed. In ASP.NET pages I'd never seen a property, just fields. If you use properties to encapsulate and centralize the use of this fields (usually private fields) when developing ASP.NET pages you can improve your design and code will be more readable and maintainable. OK, you have a problem with properties in ASP.NET, you can't store the value of the property in a private field storaged in memory.... really? You can use ViewState, Session, Cache, Application.... instead of a private field to guess it. You can see an example in a previous post: Web Forms are also Objects...

• Handling Events (No Business, just events).

When I say events I want you to think on control events (DropDownList.SelectedIndexChanged, Button.Click...). Events are the only way the user can interact with the pages, but this is design, no Business. I think is a best practice extracting the logic usually coded in the event handlers into private methods. You have a private method that adds a new row in a grid, but you don't care if this line should be added when the user clicks on a Button or when a DropDownList changes it selection. From this event handlers, you should invoke the private method to add the new row, but I think is better not to code directly in the event handler. Doing this way, changes in user interface will be easyer to develop.

• IsPostBack… USE IT!!!

Every line of code outside an "if (!IsPostBack)" condition should be justified. Of course, if you're handling control events you're in a PostBack. I mean each line of code placed in the common life cycle methods (Init, Load, PreRender, Render...). This methods will be invoked in every PostBack, so you must be really sure that this line is really needed out of a not IsPostBack condition, or you will be executing more than required, loosing performance and increasing bugs (more lines executed, more bugs).

• Don’t code for UI, code for Business.

If you think on Databases design, this is obvious. Lets apply it to the other interface, the UI. I think there are two interfaces in distributed applications, the Database and the User Interface. Just before store data, and just before show it to the user, we usually need to format it to the appropriate data type (or format). But we should avoid to use a string to store a date value just because Database need it or the user prefers to see it in a different format. I mean, use always strongly typed entities and properties all along your application, and make the needed changes as late as possible. Doing this way, you don't have to worry about the correct format of the string containing a date value. In the other hand, think the same way parsing input data from the user, but doing it as soon as possible.

• Do the simple, do the best.

Notepad never fails. Word never...., sorry, I can't lie. I can put lot of examples that demonstrate this tip, but I think this is the easy one. The really difficult thing is not to forget it.

• Read, learn and think.

IT world is moving quickly and get changes each day. You don't have to be an expert on each new technology (I think is impossible), but you need to know something about where IT trends. Just knowing several ways you can choose the correct one. I think is more important to know what it could be done than the way it could. If you know something can be done, you can ask your colleagues, Google, forums, blogs... I'm sure you will finally find a solution. If you don't know something can be done.... you can't find the way.

As you can see, this is not a standard Best Practices article. Feel free commenting each tip, I hope you do it to get a better final version of this tips adding to them all your knowledge.

Thanks for the time.

This is something that made me crazy some months ago.

As you probably know, DropDownList and ListBox have the same base class, ListControl, and both use ListItem to add Items to their collections. The difference between both controls is that DropDownList can have just one Item selected, while ListControl can have many Items selected at the same time.

At runtime, you have two different ways to select items in both controls. You can set the Selected property of the ListItem you want to select to true, or set the SelectedIndex property of the controls to the index of the ListItem you want to select. Both are valid, but for the DropDownList the second one is better than the other because there are no checks to avoid multiple selection. If you have set more than one ListItem.Selected property to true, you'll get an Exception when the control is rendered.

Conclusion.

While you are working with DropDownList, try not to use the Selected property of the ListItems to change the selection of the control. If you want to select one Item, get the Item with one of this methods (ListItemCollection.FindByText(string Text) or ListItemCollection.FindByValue(string value)) and then set the SelectedIndex of the DropDownList to the result of the method ListItemCollection.IndexOf(ListItem item). Doing this way you won't have any problem.

I hope you find this useful.

I know all of you are thinking that I'm stupid. Of course, everybody knows Web Forms are objects. But why, if everybody knows, not everybody thinks on it when developing web applications?!

You can have the best Architecture, the best Data Access Layer, the best Business Rules and Objects.... what happens with pages?! Pages are always the worst part of any web applications I've ever seen. Coupling, modularization, abstraction, maintainability... are things that doesn't be cared in web pages.

I know (and suffered each day) about client requirements. Windows designs tried to put directly into web pages that make us to code lots of lines in JavaScript. But really I think that this isn't the main problem. I think the problem is that when a page is finished, you can ask the developer who has coded about what happens if the user clicks here and the change this value and... he doesn't know.

I think a way of improve Web Applications development is taking care about the design of the front-end. Pages are the only way users can scratch our code, because the front-end is where they can interact with the application. Is good to design "the perfect" Architecture and so on, but thinking that pages are just objects with some properties and some data showed in a different way depending on those properties.... I think the time spent developing the front-end and the number of bugs on it shouldn't be so higher.

I'm writing an article about it but I'm not sure when it could be finished. Somethings included will be.

- Page_Load always execute, even when the page won't be rendered again (in navigation, when you close it). Is this line really necessary out of the typical if (!IsPostBack)... ? Think about it and try to refactor it. 

- Try to design your pages as decoupled as you can from the rest of the application. This is even more important if the coupling is between pages.

- Use private properties as flags to configure your object (your page). You can do things like this if you are waiting for that key from the previous page, or use ViewState if you just need this property during the postbacks.

 private long theKeyINeedToLoadData 
{ 
 get 
 { 
  if (Session["theMagicKey"] != null) 
  { 
   return (long)Session["theMagicKey"]; 
  }
  return -1; 
 } 
 
 set 
 { 
  Session["theMagicKey"] = vale; 
 } 
} 

- Check this "really needed to work" properties as early as possible, and if you detect a problem stop execution. Show an error, redirect to some general page... but I'm sure at this point you already know something will goes wrong if you continue to the end of the life cycle.

I hope I have enough time to finish this article, and then put it here to argue with all of you and learn together about it.

Feel free commenting anything about this, I think is really important and interesting.