March 5, 2011
I recently created an MVP framework (http://nucleo.codeplex.com) that I was in the process of porting to a Silverlight 4 library for a project I’m working on. As I was linking code to the project, I quickly realized that since the SIlverlight 4 is a subset of the .NET framework, I was running into issues with the custom code I was using, and this spurred off a philosophical debate in my mind: do I worry about creating my own custom components to handle the scenario, or do I refactor and leverage what’s already in the .NET framework?
I could very easily get caught into a whirlwind of wrappers, facades, and my own design of components to handle the situations I was dealing with. I could also embed “if #SILVERLIGHT” everywhere to handle some of the scenarios I ran into. On the other hand, if it’s already done for us in a way that requires some sacrifice of features or changes to the core code, is there value in this? In reality, it depends. Going to Silverlight, some components available in a web or windows app may not be in the Silverlight framework, forcing us to develop the feature we need anyway. On some level, this is why developers create custom wrappers, facades, or adapters, because as environments change, certain framework code may or may not be present. The converse can be true too: as environments change, our custom code could break, and using the framework would have prevented a refactoring. In some ways, design can be a double-edged sword very quickly. This of course depends on the type of application; a two-tier traditional web application may not need to be concerned, whereas an n-tier application may need to contemplate what it would take to share the middle layer to a variety of front-ends.
However, an environment change can consist of a change from waterfall to agile development, and as such TDD also becomes a factor in that design, an often reason for developers to approach the design with abstraction in our own code in the first place. Those that come from an ASP.NET web forms background knows the ASP.NET framework is tightly-coupled with the web and as such is harder to test, unless you resort to wrappers of services, etc. One of the core features I saught to implement in my framework was wrappers for the various services a developer may use; sure, HttpContextBase base class is nice, but it tends to be tightly coupled with the web, and as such, a wrapper to expose one small portion of functionality comes in really handy here.