Charlie Takes Inspiration from Cuyahoga
Four years ago, I had no programming experience beyond creating a handful of scripts for Lotus 1-2-3 many years earlier. The design company I worked for decided that it needed a website. Because I was the resident “computer nerd,” the task fell to me to create the website. With HTML 4 for Dummies at my side, I created the REB Design website. Feeling proud of myself, I went on to create the website for Modular Shades & Shutters.
As many of REB’s clients were retailers, I suspected that we’d soon be asked to create a website with a shopping cart. I telephoned our ISP and asked them what we needed to do in order to have a shopping cart on a website. “Learn CGI,” I was told. In my bookshelf to my left, the cover of Learn Perl in a Weekend glistens, its spine barely broken. Our networking contractor happened to see me messing about with Perl, and recommended that I learn ASP instead. A few weeks later, another computer contractor happened to see me messing about with ASP, and recommended that I learn ASP.NET instead. (I suspect that if another computer contractor had walked in around that same time, I might be using Java today.)
I worked through ASP.NET for Dummies, and then ASP.NET Unleashed. Feeling that I had a grasp of the basics, I felt it was time to learn how to put all the pieces together to create a full ASP.NET website. I downloaded the IBuySpy Portal starter kit and then, .vb file by .vb file, re-created the starter kit from scratch. If I came across some code that I did not understand, I would research the topic until I understood what that code was doing. Only then would I add it to my re-created portal website. I did not re-create the entire starter kit, but enough for me to understand how it did its thing.
This is a little bit of background that will explain the next stage in the life of Charlie.
In late November, after Charlie’s hiatus, I had finished reading through Coder to Developer and Code Complete. I had created my Feature Set, Software Specification, and broad Architecture. But I still did not know how to start. As you will see from my background, my only “development” experience has been to download the IBuySpy Portal, pull it apart, and put it back together. I decided to do the same thing again, just to see how someone else had gone about developing a website framework.
I looked at a number of open-source website frameworks, and decided upon Cuyahoga. I contacted its author, Martijn Boland, and asked whether he had an archived version of Cuyahoga 0.1. I explained to him that I wanted to re-build it from scratch, to learn how he had started Cuyahoga. Martijn provided a link to the first version of Cuyahoga and, like any inquisitive kid, I immediately pulled it apart to see how it worked. Then, I re-created it from scratch. Rather than re-creating it line-for-line, which I did with IBuySpy Portal, this time I added my own twists.
I learned four main things from re-building Cuyahoga version 0.1, which have had a substantial impact on the way Charlie has since developed.
First, I learned the value of Reflection. To a self-taught developer, it can be hard to understand the benefit of Reflection. After all, we code these classes, we know their methods and properties, so why on earth would we need to use Reflection to learn what we already know? Well, the answer is that we use Reflection when an application does not already know about a class and its methods and properties. This would be the case when we plug a new component into an existing application. The application can then use Reflection to inspect the plugged-in component and make use of that component. Put another way, Reflection means that once we have created the main application, we can create plug-in components without having to go back into the main application and change its code.
Second, I learned the value of Interfaces. I already knew what an interface was and why we use them, but I had never truly known when to use an interface. Like Reflection, the answer is we use an Interface when we do not already know what specific class we will be using. Reflection and Interfaces work hand-in-hand to allow an application to make use of plugged-in components. When we plug in a new component, Reflection allows an application to find any new class and create an instance of that class, and its Interface allows the application to use that new class. For anyone who would like an introduction to interfaces, I wrote what I hope is a neat little example on the ASP.NET Forums: Why does the .Net Pet Shop 4.0 use so many interfaces?
Third, I learned the value of Composition. Again, I already knew what composition was about, but I had not really known when to use it. Textbooks tell us that we use inheritance when one class “is a” type of another class (a Car “is a” type of Vehicle), and use composition when one class “has a” type of another class (a Car “has a” type of Engine). That’s fine for textbooks which use real-world objects. But when the code is dealing with fabricated objects (objects that do not exist in the real world), it is much harder to know when to use composition over inheritance. Cuyahoga’s business objects used composition in a way that was easy to follow and easy to appreciate.
Fourth, I learned the value of O/R Mappers. Here though, I decided that the value of an O/R Mapper was nil. Version 0.1 of Cuyahoga provided a typical Data Access Layer that used the familiar Command.ExecuteReader method to retrieve data and put that data into business objects. But version 0.2 and later of Cuyahoga uses NHibernate. The simple Data Access Layer Component was banished, to be replaced by dozens of XML files in amongst the business layer objects, and lots of code to support NHibernate and its sessions. Frankly, I cannot see the benefit. Database access code may be boring to write, but it leads to code that is very simple, and provides a single point at which we can tweak data access (such as minimising the number of trips to the database). One piece of advice from the Aardvark is that simple is better than complicated. I agree, so I decided that Charlie would eschew O/R Mappers and instead use a simple, handwritten Data Access Layer.
Having re-created version 0.1 of Cuyahoga, I felt that I had a much better understanding of how Charlie would be designed. A number of ideas had started forming, and I decided that with just a little more research, I would be truly ready to embark on creating Charlie. I’ll talk about that research in my next post.
Let me close by expressing my true gratitude to Martijn Boland for contributing Cuyahoga to the open-source community. I learned an enormous amount by working through its code. Thank you, Martijn.
by Alister Jones | Next up: Back to Basics →
----
Post a Comment