Providing Charlie with an Extended Framework
I am a self-taught developer. Because I have no formal training in programming, there are fundamental aspects of development that cause me great confusion. The greatest cause of confusion is the “where does it go” question that is the province of architecture and design.
Let me provide a simple example. Let’s say that I decide that I need to extend the ArrayList so that it supports automatic sorting of members (or use Peter Blum’s free AutoSortArrayList). Where does such a fundamental class go? It does not belong in the presentation, business, or data access layers. It is a utility class that could be used by any class in any layer. So where does it go?
Let me provide a different example. Let’s say that I have decided to use Paul Wilson’s ORMapper. As I am a subscriber to Paul’s WilsonDotNet.com website, I have the source code for the mapper. Where does the source code go? If I stick it within my own Data Access layer, then I am mixing my own code with third-party code. What happens if I decide that I’d rather use NHibernate? I need to rip out one set of third-party code and put in its place another set of third-party code, and then update all of my own code to make use of the new OR Mapper. This cannot be how seasoned developers work. So again, where does it go?
To solve this problem (or perhaps to avoid it altogether), I have decided to introduce a layer between the .NET Framework and my Charlie application. Any component that extends the .NET Framework in a generic way (not specific to Charlie) goes into this new layer. As the standard .NET Framework Class Library uses the System namespace, this extended class library will use the XSystem namespace.
Let’s return then to the example of the AutoSortArrayList. As the standard ArrayList is within the System.Collections namespace, I place the AutoSortArrayList within the XSystem.Collections namespace. What I would do is create a new AutoSortArrayList class that simply inherits from Peter Blum’s class. That way, I get the namespace I want, and I get the opportunity to extend his code if I care to.
Let’s return to the example of the ORMapper. As Paul’s component was based on the original design of .NET 2.0’s ObjectSpaces, I would elect to place it within the XSystem.Data.ObjectSpaces namespace. I then create a facade to Paul’s component. That way, I get the namespace I want, and I get the opportunity to extend his code if I care to. This also means that I can easily swap in a updated version of Paul’s component. I could also replace Paul’s component with NHibernate and change my facade class so that NHibernate works like Wilson ORMapper. This would minimise or eliminate any changes required in the Charlie application.
Another example is that I may find that I’d rather use Paul Wilson’s MasterPages component rather than the MasterPage class built into ASP.NET version 2.0. Charlie can simply switch from using the System.Web.UI.MasterPage class to using the XSystem.Web.UI.MasterPage class. What could be easier?
This is why, when designing Charlie, I will strive to distinguish those components that are application generic (they go into XSystem) from those components that are application specific (they go into Charlie).
by Alister Jones | Next up: Source Code Control System →
----
Post a Comment