In almost every web project of any size, you would probably use a lot of user controls to separate the content and UI logic. Many of the user controls are used only at one place in the solution while others are used by various pages and other user controls.

The ones that are used throughout the website needs to be generic and loosely coupled from the context in which they are used. If not, they would contain a lot of code only to cater for the needs of certain pages or other controls in which they are embedded. This is bad.

The rules of object oriented programming apply to ASP.NET just as much as for code libraries, which include loose coupling, encapsulation, high cohesion and polymorphism. This is easily forgotten due to the apparent differences between classic programming and ASP.NET development.

Loose coupling

A user control should not contain any context specific code, but only do the one thing that it was designed to. If the control is called AddComments.ascx it should do nothing more than add comments. Look at the name and use it as a guide for what it should do, and equally as important, what not to do.

By making it loosely coupled you gain a lot of flexibility and reusability for the user control. You could even use it in other web projects because it is not dependant on the context in which it lives.

Encapsulation

The inner workings of a user control should be kept invisible by the user of that control. That is does simply by making the various members private. The AddComments.ascx control only has to expose two properties and that is Name and Comment. Those properties should be made public and everything else should be kept private.

If the user control has some kind of events like a button click event, that button should not be public so the page can listen for the click event. Instead, you should create a public event that you raise internally from the buttons click event handler. By exposing the button you make it harder to understand and use the control. Here is how to add events.

High cohesion

Keep the control focused on the single task it was built to solve. All the methods should relate to each other in some way, so you don’t end up having generic code in them.

In the AddComments.ascx control you might have some methods that clean the entered comments so it doesn’t contain any JavaScript and other nasty things. You should consider moving those methods out of the user control, because they could represent a core functionality that isn’t that much related to adding comments.

If you don’t, you could end up with a huge class that does a lot of other things than adding a comment. That damages maintainability and removes focus of the real problem that it solves.

Polymorphism

If you have more than one user control that exposes some of the same properties because they are used in much the same way, you should consider implementing a common interface. That makes them more flexible for the page to use, because it can treat them as they were of same type.

If they share more than just public properties, then a base class is the way to go. The base class can provide common functionality to be used within the user control, so it doesn’t have to be implemented into every one of them.

Polymorphism is only applicable to user controls that bare resemblance to other user controls within the same website.

Remember to refactor

Refactoring an ASP.NET project is nothing like refactoring C#/VB code in practice. Even though the principles are the same, it is much harder to move pieces of a page into a user control. It is even harder to refactor a user control that has grown to big into smaller controls, because that user control might be used in many places throughout the website. More on ASP.NET refactoring.

Conclusion

By adhering to the principles of object oriented programming when designing user controls, you can maximize the maintainability and reusability of the controls. The key is to remember that despite ASP.NET looks very different from C#/VB code libraries, it is still programming and in programming you code using well proven principles. ASP.NET is no different.

To learn more about object oriented design principles or just to touch up, I found this easy-to-use guide.

A week ago I wrote about the native client callback feature of ASP.NET 2.0 and why it isn’t always the smart choice. That post got me some good feedback that inspired me to build a custom callback implementation so you wouldn’t have to use the native one. I could just use other AJAX libraries such as ASP.NET AJAX or Ajax.NET, but that’s not fun.

When I started thinking about this little project I imagined it to be complex, but actually it turned out to be extremely simple with very little code. It is less than 100 lines of code including the JavaScript and code comments. Remember, that this is not an all-in-one AJAX framework, but a simple and fast way to do client callbacks.

Good things

• Uses GET instead of POST for performance reasons
• Doesn’t send the ViewState to eliminate the overhead
• Simple implementation

Limitations

Because it doesn’t send the ViewState you are not able to check the state of the controls on the page. You can use the Session and Cache and any other store, just not the ViewState. You cannot implement it on custom server controls, because it only works on pages.

Implementation

The solution consists of two things: a base class for the page and a small JavaScript file.

Step 1 - change inheritage

In the page you want to do client callbacks, just inherit from CallbackPage instead of System.Web.UI.Page and override the IncommingCallback(string argument, string context) method. Here is an example of such a page’s code-behind file.

public partial classdefault : CallbackPage
{
 protectedoverridevoid IncomingCallback(string argument, string context)
 {
  if (context == "verify")
  {
   if (argument == "william")
    base.SetCallbackResponse("true");
  }
 }
}

Step 2 - Insert JavaScript

Next, add the JavaScript file to the header of the HTML document or copy its content into your own script file.

<script type="text/javascript" src="scripts/callback.js"></script>

The JavaScript file contains one method that creates the callbacks and it is called CreateCallback. I'll show you how to use it below. That’s the entire implementation.

Example of use

Let’s imaging that we want a text box where the visitors write their name. When they click a button, it verifies the entered name server-side and sends the result to a JavaScript function.

Step 1 - Create JavaScript method

Let’s start by adding the JavaScript method to the page:

< script type ="text/javascript">

function NameVerifier(response)

{

  if (response == "true" )

    alert( "You are verified" );

  else

    alert( "You are not verified" );

}

</ script >

Step 2 - Call the method

< asp : TextBox runat ="server" ID ="txtName" />

< input

  type ="button"

  onclick ="CreateCallback(NameVerifier, document.getElementById(' <%=txtName.ClientID %> ').value, 'verify')"  
  value ="Create callback" />

Notice the onclick event of the button. It calls the CreateCallback(callback, argument, context) JavaScript method. The callback parameter is the name of the JavaScript method that should be called when the callback returns with the result. The argument parameter is the value that you want to send to the server-side IncomingCallback method. The context parameter also goes to the IncomingCallback method and it is used to separate the different callbacks you have on a page.

The SetCallbackResponse(string argument) server-side method sends the argument parameter back to the client – if it isn’t called, nothing is sent back.

Download

The zip file contains the base class and the JavaScript file.

CallbackPage.zip (1,17 KB)