(X) Hide this
    • Login
    • Join
      • Say No Bots Generate New Image
        By clicking 'Register' you accept the terms of use .

Silverlight 2: Custom Controls vs. User Controls

(0 votes)
0 comments   /   aggregated from To Code or not To Code on Apr 11, 2008   /   original article
Categories:   General

Silverlight_Logo_thumb In my first post on Silverlight 2 I concentrated on how to use User Controls in a Silverlight application.  Since I started writing this post, Scott Guthrie and numerous other developers have also written posts on User Controls.  One thing neither of them cover though is when to use them.  With most technologies there are numerous way to accomplish many tasks, Silverlight is certainly no exception and one example of this comes in the form of User Control vs. Custom Control. 

This post is different than my other Silverlight posts as I'm not showing any code and don't have a cool example to talk about.  This post is meant to be more of a discussion on the differences between User Controls and Custom Controls as well as some guidance on when to use one over the other.  Much of what I'm writing here is just opinion though so if you have a different though or if you find something that I have completely wrong please comment.

Definition

First off let me say that I haven't used Custom Controls much yet so that may sway me a little but I'll try and be open minded.  I'll also say though that it does appear that creating a custom control in Silverlight 2 is significantly easier than creating a custom control in ASP.NET.  Much Easier.

Custom Controls and User Controls both accomplish many of the same goals although in different ways.  It seems to me that this question is nearly the same in Silverlight as it is in ASP.NET, and I suspect with much the same answer.

User Controls

The Silverlight documentation gives two reasons for creating a User Control:

  1. To separate functionality into smaller, manageable pieces of logic that can be created independently from an application and other controls.
  2. To group related controls that can be used more than once in an application.

In practice, user controls are used extensively for both of the reason listed.  One of the great things about them in the ASP.NET world, and now in also in the Silverlight domain, is the ease with which they can be created and reused.

Custom Controls

Custom controls can be loosely defined as creating a control that is based on (i.e. derived from) an existing control and extends its functionality in some way.  Some reason they may be built are to add a capability not included in the base controls, make a company specific version of a control or to group several controls together to perform a specific function.  This last version, grouping several controls to perform a specific function, where the big overlap with User Controls occurs.

One other advantage of custom controls is that since they are compiled into a .dll, they can be reused in multiple Silverlight applications where a User Control is limited to the application in which it is created.

Scenario

While I was working on a new Silverlight 2 project a few weeks ago I had this scenario:

I want multiple blocks to have the same base behavior, such as being resizable, moveable and a similar look/feel.  However, I wanted the contents of these blocks to be different.

With the custom control vs. user control question I went to what is becoming an incredible resource when you are looking for advice but not big text references: twitter.  I happened to know that at least three recognized Silverlight experts (TheADOGuy, LBugnion and WynApse) were on twitter at that moment and that they were following me so I sent a question which resulted in the following conversation (minor editing for clarity):

johnnystock SL2 gurus: If I want to make a custom container object to handle things like drag/drop, look/feel etc. should it be user or custom control?

LBugnion @johnnystock Does your container have an intrisic look&feel, or is it going to change its look often?

TheADOGuy @johnnystock I suggest you derive a custom control from "Panel" but not knowing all your req's that might not be perfect

johnnystock @LBugnion Look/feel will be same for all instances

johnnystock @TheADOGuy Is there a SL2 panel? I was thinking of deriving from Canvas

LBugnion @johnnystock I use UserControls when the look&feel of my control is more or less similar (changes can be handled by styles)

LBugnion @johnnystock and CustomControl for truly lookless controls, where L&F changes a lot depending where they're used

LBugnion @johnnystock That said, the sugestion to make a custom Panel sounds pretty good!

johnnystock @LBugnion That's what I like to hear as personally I find User Controls easier than custom controls :)

LBugnion @johnnystock If you check MIX sessions, Robbie Ingebretsen shows how to create a custom WrapPanel. A good start for what you do

LBugnion @johnnystock Custom Controls are harder to understand, but flexibler to use.

johnnystock @LBugnion cool, thanks for the tips and I'll check tat session out

LBugnion @johnnystock but I do a lot with UserControls too.

TheADOGuy @johnnystock Yes, its the abstract class under all the containers...look at the class def of Canvas in the .chm...

LBugnion @johnnystock The session is Nerd + Art, around 00:46:00

From the above discussion it doesn't really look like there is always a clear cut line on when one type of control is better than the other.  Well, I think there are cases where custom controls are clearly correct, and cases where user controls are clearly right, but there is also a quite large overlapping gray area.  The gray area is seems mostly populated by container controls as well.  It seems like developer preference definitely plays a major part in the decision when in the gray area. 

For what I'm trying to accomplish I will probably be using both.  The functionality will be broken into user controls but the container that houses that user control will be a custom control.  In fact, the only reason I'll be using user controls at all is to reduce clutter and make multi-person development easier as the functionality will not likely be reused.  In my opinion those are valid reasons to use a user control, even though they are not the stated purpose of them.

Conclusion

I am by no means an expert on custom controls but I do have a lot of experience with User Controls and for me I don't know that there is a simple line to choose between here.  Personally I use something like this to help make the decision:

  1. Will this control be used in multiple applications? - probably Custom Control
  2. Is there a base class that has the majority of the functionality needed? - probably Custom Control
  3. Is rapid development a factor? - probably User Control
  4. Am I building it or just specing it out? - probably User Control if I'm building
  5. What am I more comfortable coding myself? - User Controls

Does anyone else have any criteria they use?  I'd love to hear feedback on your preferences as well.

Digg!   kick it on DotNetKicks.com

Subscribe

Comments

No comments

Add Comment

Login to comment:
  *      *