Tuesday, April 11, 2006
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?
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.
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.
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.