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.