It seems like I've committed (not exactly sure how) to present a session at the forthcoming ASP.NET Connections Conference entitled "Do Design Patterns Make Sense in ASP.NET?". Since I tend to describe myself as an upgraded VBScripter, with only a passing knowledge of complicated stuff such as object orientation, classes, interfaces, and delegates, this came as a bit of a shock. OK, so I did propose the session during what must obviously have been either a blur brought on by Yuletide alcoholic over-indulgence, or a momentary lapse into some elated state of being when some code actually worked first time. Or maybe, and this is more likely, it happened when I wasn't suffering one of my momentary lapses into sanity.
Anyway, as I enjoy a challenge (for example, I'm writing this diary entry in NotePad), I've decided that rather than phoning the organizers and apologizing for this outrageous assumption of capability on my part, I really ought to have a go at it. The reason being that I actually want to attend this session myself. And, as nobody else seems to be presenting it, I guess the only way I'll get to see it is from the hot seat at the front.
The fact is that, for many people whose historical involvement in Web development was based on classic ASP, the move from VBScript (or JScript) to .NET has been just a little traumatic. I love ASP.NET and the features and capabilities it opens up compared to classic ASP. And being able to escape from a reliance on COM components and all the associated junk they require (such as registration) was like a breath of fresh air. I even use a proper dev environment now (Visual Studio rather than NotePad), and Dave says I might even one day get to be a "proper programmer".
The issue is that, unlike ASP - where structured programming and good architecture were often more a dream than reality - ASP.NET actually allows you to write real code. Whilst only the most charitable would call VBScript an object-oriented language, VB.NET and C# let you be a real developer and write structured code that follows best practice. And good coding practice is increasingly being related to the use of design patterns. However, like many Web developers, when I started to hear the term "design pattern" being used more and more frequently, I was a bit scared. I am too old to have had a basic education in object-orientated languages at school, and so having to pick it up as I went along means anything that smacks of theoretical philosophy is just a bit frightening.
Of course, design patterns themselves aren't physically scary; it's more the way they are written (you need to have a grasp of UML), and the sometimes almost religious fervency with which they are promoted within our industry. Most people use "informal" design patterns anyway, such as structured exception handling and object lifetime management though the "using" construct. And design patterns do, if properly applied, help to create code that is more reliable, reusable, and extensible. I am a believer, but - I guess like many people - I find it hard to relate their use to ASP.NET applications.
For example, using code-behind and a separate data access component provides a simple implementation of the Model-View-Presenter design pattern, although many people seem to suggest that this is Model-View-Controller rather than Model-View-Presenter. In addition, the built-in ASP.NET provider model and adapter framework match the corresponding design patterns well, so adding your own providers and adapters should automatically implement these design patterns. And many classes in the .NET Framework, such as XmlReader and the provider-independent DbProviderFactory class, implement the Factory design pattern so you are automatically taking advantage of that. Plus, the HTTP pipeline itself, and the ease of extending it, follows the Intercept Filter pattern.
Where I struggle to see the advantages are in the command- and event-oriented patterns. Unlike a Windows Forms application, ASP.NET pages are "one-shot" and raising events has little real advantage outside of the currently executing page. It seems to me that there are many patterns that have no real applicability within ASP.NET. Certainly, exhaustive searches of the Web for examples turn up few (usually no) examples of their use. Even the useful patterns & practices document "Enterprise Solution Patterns Using Microsoft .NET" omits many common patterns, and only briefly mentions some others.
So, here's the challenge - help me out. What's your take on this, and what patterns do you use in your ASP.NET applications? Drop me a line at firstname.lastname@example.org. It would be useful to have some real-world comments and opinions for the session, and (if you wish) I'll make sure you get a credit in the slides and tell the attendees - assuming some turn up for the session - how other developers use design patterns.
Meanwhile, I raved last month about the Soundbridge Internet Radio, which allowed me to avert a critical upcoming relationship situation by bringing Planet Rock into our kitchen. So, after a month, what do I really think of this amazing technological device? Well, as with most things, experience reveals both plus and minus features. On the plus side, I was impressed by:
However, there are a few problems as well. Like Media Center, these just tend to take the edge off the total experience, and suggest that it isn't quite yet a mass-market consumer device:
So, overall impression? Yes, it's a great device - if rather expensive - and has the feel of a quality product. And as it can auto-update the software, hopefully some of the problems will be fixed over time. Anyway my wife loves it, so that's the main thing!