An article from ScottGu's Blog, where you can download some slides and samples about new things in ASP.NET 2.0 that make web development easier. I've seen the slides and I've found them really interesting.... but I can't enjoy the samples yet (I don't have enought time).

The article: ASP.NET Connections Tips and Tricks Slides+Demos Posted

Hope you enjoy.

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.

I know the title is strange. Compilation error trying to execute a page? Well, continue reading and you will understand.

You know all languages in .NET are OOP languages, so pages in ASP.NET are also objects. When you compile an ASP.NET project, you just compile the code-behind code but, what happens with the *.aspx files? The code in this files is parsed to several *.cs files (one per page) and compiled on demand.

Trying to give a funny speech to my team about ASP.NET best practices, defensive programming, standards..., I began to play with a page and place a default constructor on the code behind. Nothing happens. Ok, is a class and it could have a constructor. You really can't do something useful here, but you can code it.

Try again with a private constructor. Compile the project and execute. Here you have the "Compilation Error executing ASP.NET Page":

Compiler Error Message: CS0122: 'DemoCharla.AspxWithConstructor.AspxWithConstructor()' is inaccessible due to its protection level.

As you know, in the @Page directive in *.aspx file you specify Inherits attribute. This really means that the *.aspx files inherits code-behind classes, but obviously, after parsing them to corresponding *.cs files and compiling.

Just one useful thing is that you can see the source code of the generated *.cs file in the error page, clicking in the "Show Complete Compilation Source" link This is the same as you can see in the "Temporary ASP.NET Files" folder behind \Framework\< version >\ folder. If you go there and look inside your folder project, you will find a folder with a name like 5e170680 (this name is always different, but have the same format) and inside this folder you will find another folder with similar name. Here is where all the temporary files are generated. You can see *.cs files, *.cmdfiles which contains necessary parameters for compilation, the *.out and *.err as a result of this compilation and more.

You can try and enjoy for a while seeing all this files, and executing a page and seeing csc.exe in the process monitor compiling pages for the first time. Isn't really useful but is what really happens "behind the scenes".

There's a good article in Code Project from Natty Gur: http://www.codeproject.com/aspnet/ASPXFILES.asp

Hi again.

In all the web controls that inherits from System.Web.UI.WebControls.ListControl (DropDownList, ListBox...) we have 2 ways to add items in runtime:

- TheControl.Items.Add(ListItem item);
- TheControl.Items.Insert(int index, ListItem item);

I'd found a funny thing using the second one. If you try to add a null Item using the first one, we get an Exception just in that line, but using the second one we also get an exception but now when the page is rendering. ¿Why both are diferent? I don't know but it can be a problem because you can't catch the exception in the appropiate place. Using Insert and adding a null Item the SelectedIndex property is also null (if there are no items selected it should be -1), so trying to access it will throw an Exception also.

Ok, I know nobody will do this, at least not directly ( Items.Insert(0, null) ), but I think it wouldn't be bad practicing defensive programing here. Perhaps you have coded a method that returns a ListItem, so in this case be sure to check if the returning ListItem is not null.

Isn't really a technical bug (perhaps design), and if it happens is really easy to detect, but I post it here because it makes me laugh for a while.

Nothing else today.

No one wins, both are the same :-(.

In the project I'm currently working, we need a real UserControl.IsPostBack property, so we had to create a new one in our CustomControlsBase class, named IsUserControlPostBack. This new property is really useful because we need to avoid database round trips if data is already loaded in the control and so on (just the same like Page.IsPostBack, but inside a UserControl).

Some lines of code will explain better what we did to implement it.

//ReadOnly property.
protected bool IsUserControlPostBack
{
    get
    {
        return this.ViewState["IsUserControlPostBack"] != null;
    }
}

//Initializing the new variable updating ViewState data.
protected override void OnLoad(System.EventArgs e)
{
    base.OnLoad (e);

    if (!IsUserControlPostBack)
    {
        this.ViewState.Add("IsUserControlPostBack", true);
    }
}

Doing this way, we are always sure about when the UserControl is loaded due to a client PostBack, and when for the first time. I think it's a good use of the ViewState.

I hope you find this useful.

--------------------- Added to explain why I find it useful. Thanks ADI for your comments ------------------

This property wouldn't be useful is you are loading your usercontrol at the same time you load the page but, if you want to load a usercontrol after the page is loaded, the Page.IsPostBack will be always true, so you can't know if the usercontrol is loaded for first time or not. Think on loading usercontrols if the user clicks on a button for example.

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.

Hi all.
I will try to explain how to use the JavaScript interception pattern and why I need to do it in my project to hijack the __doPostBack function.

I had to detect if user had made changes in some pages of the web application and then ask him to Save Changes. Of course, due to client requirements and performances issues I had to code it in client side, so I put some hiddens in my Base Page and code some scripts to change their values (is so complicated to explain so I won't explain this at all). I will focus on two of the functions. One of them set the value of one hidden (hiddenHasChanged) that tell me if page has been changed to true, and the other evaluate this hidden and if it's value is true, ask the user for Save Changes and store the response of the confirm dialog in other hidden (hiddenSaveChanges). Then I check the value of the hiddenSaveChanges in server side and decide to save changes or not.

To modify hiddenHasChanged I add some attributes to the controls in our custom controls library ("onchange", "SetHiddenHasChanged();"). Now I know if Page has been changed at any time but.... where can I place the code that will invoke the confirm dialog? I decide to subscribe to the onunload event and invoke it there. It looks like this:

< script>
    onunload = AskUser;
    function SetHiddenHasChanged() 
    {
        document.getElementById('hiddenHasChanged').value = true; 
    }
    function AskUser()
    {
        if (document.getElementById('hiddenHasChanged').value )
        document.getElementById('hiddenSaveChanges').value = (confirm('Do you want to save changes?'));
    }
< /script>

When I began to test it I noticed that even the value of the hiddenSaveChanges before the PostBack were the result of the confirm dialog, when I got it in Server Side code this value wasn't updated. What was happened? The new value was missing and I didn't know where. Finally I got the conclusion that, although the value was correctly updated in client side, the data sent by the request was collected before my script code was executed.

How can I fix this?

I discard using JavaScript events like onunload, onbeforeunload... no one goes right for me. I need to hijack the __doPostBack function and place me code just before the form submission. So I place this script code in my Base Class. Notice you can't place this code in the <Head> section because __doPostBack doesn't exist yet, so I have place it just before the close of the <Form> tag.

< script>
    if (typeof(__doPostBack) == "function")
    {
        var __doPostBackOLD = __doPostBack;
        __doPostBack = function(eventTarget, eventArgument)
       {
           ModifyHidden(confirm('Do you want to save changes?'));
           __doPostBackOLD(eventTarget, eventArgument);
        }
    }
< /script> 

Doing this way I'd fix the problem. I've seen this pattern used with Page_ClientValidate function, and even with __doPostBack but never to modify data, just to avoid the submission of the form when some data is wrong, or to show a "Please Wait" message during PostBacks. This pattern obviously is not new, but perhaps the use of it.

I hope you find it useful. What do you think about?

One of the Best Practice in ASP.NET projects is to develop a Custom Controls Library to encapsulate and centralize all the common code and custom features we want in our application. All changes made to a control will affect all the pages having this control, so we earn time and detect bugs more efficiently.

Of course, in the project I'm currently working we have all the UI Controls as Custom Controls, but we have had some problems. In some of the Custom Controls, we had to add some client logic in JavaScript. We did it adding javascript handlers for some client events of the controls, as "onclick", "onblur" and so on. The problem is that we did it in the Page.PreRender time, and we override the previous attributes added in some pages. I think is better to me if I explain it with some lines of code (I'm sorry but my english is not as good as I need now...)

1.- Adding attributes to handle client events. This code belongs to a Custom TextBox.

protected override void OnPreRender(EventArgs e)
{
    //more code
    this.Attributes.Add("onchange", "ChangeForeColor();");
    base.OnPreRender(e);
}

2.- Use of the Custom TextBox in a Page.

protected void Page_Load(object sender, EventArgs e)
{
    //more code
    txtOne.Attributes.Add("onchange", "ValidateInput();");
}

3.- Explanation.

Now I'll try to explain it. In the first piece of code, we add an handler to the "onchange" event of the textbox that will change the color of the text on it. This behavior is requiered in all the application, so we placed it in our custom TextBox. One of the developers, need to add another handler to the "onchange" event to validate the input. He was new in the project and he didn't know all the Custom Controls behaviors yet, so he did what anyelse would do: put in his page the second piece of code. Of course, the handler of the developer never was executed. He asked us and we saw the problem. We were overriding his code!!

4.- The solution. We add this method to the Custom TextBox to avoid this problem. Prior adding our handlers to an attribute, now we check if there's any handler added by a developer and we always add all of them. We will never override developers code again!

protected override void OnPreRender(EventArgs e)
{
    //more code
    //Old Code 
    //this.Attributes.Add("onchange", "ChangeForeColor();");
    //New Code 
    AddAttributeSafely("onchange", "ChangeForeColor();");
    base.OnPreRender(e);
}

private void AddAttributeSafely(string attributeType, string attributeValue)
{
    if (attributeType.Length == 0 && attributeValue.Length == 0)
    {
        return;
    }

    if (Attributes[attributeType] == null || Attributes[attributeType].Length == 0)
    {
        Attributes.Add(attributeType, attributeValue);
    }
    else
    {
        string existingAttribute = Attributes[attributeType];
        if (existingAttribute.IndexOf(attributeValue) == -1)
        {
            Attributes.Add(attributeType, existingAttribute + attributeValue);
        }
    }
}

I hope you find this useful in your projects.

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.