Custom Controls Everywhere – In XAML

You’ve heard me preach it before.  Custom Controls Everywhere, damn it!  It’s my mantra, my MO, one of my core beliefs for application development.

As I started getting used to XAML, I kept thinking about how I’d implement custom controls everywhere and utilize the pattern in the same way I have before.  Since the concept applies equally well to ASP.NET and WinForms, I of course assumed that I would want to apply it to XAML (either Silverlight or WPF) too.  However, while actually doing my work in XAML, I restrained from creating custom controls right off the bat, instead waiting for the indication that I’d actually need them.  I knew the time would come, but I wanted to wait until the last responsible moment to implement them, making sure that I was implementing them A) for the right reasons; and B) in the best manner.

Update… I have changed my mind on what you’re about to read.  Be sure to see the follow-up article here.

Well, I’m about 2 months into working with XAML now, and I am yet to find a need for using custom controls everywhere.  The stock controls are working quite nicely, and when they lack some sort of presentation or behavior that I want, styles, attached properties, and attached behaviors come to the rescue.  With the combination of these 3 techniques, you can pull off some amazing things with stock controls.  Attached properties and behaviors are just really, really cool.  They are what ASP.NET and WinForms have been missing, and what I think is the key to being able to discontinue custom controls everywhere.

So I’ve now ridded myself of the instinct that a Silverlight developer would want to create custom controls everywhere when creating a Silverlight-based application.  Just use the controls you have, apply styles, and attach properties and behaviors.  And if you find a case where this falls short, let me know!

Update… I have changed my mind on this.  Be sure to see the follow-up article here.