The Architecture - Part 1
In the second chapter of Coder to Developer, Mike Gunderloy starts talking about architecture. I would have thought that in a book guiding coders to becoming developers, a significant portion of the book would be dedicated to architecture and design. After all, is that not one of the main distinctions between coders and developers? Apparently not, because the author dedicates only three pages to architecture, and then three pages to design (by way of patterns).
I have searched high and low for a book or website that walks a developer through the steps of creating a valid architecture. I have found no such resource. Is that an indication that there is no discernible approach to architecture and design? I cannot believe that that is the case.
The best resource I have found so far is a document provided by Microsoft’s Patterns & Practices team: Application Architecture for .NET: Designing Applications and Services. While it provides lots of great information, it is not the how-to guide that I have been hoping to find.
Having found no how-to guide for architecting and designing a software application, I decided that I would simply give it my best shot. I placed a pad of graph paper on my desk, and placed my list of features to its right (I’m left-handed).
The first decision I made was that there is nothing special about Charlie that warrants moving outside the traditional three-layer architecture. So I drew three horizontal lines across my page and titled the sections Presentation, Business, and Data Access. Then, referring back and forth to the feature set, I came up with the following first draft. Assets are business objects such as blog entries, articles, and photographs.
Having drawn the first diagram, I evaluated it.
To start with, I was not sure whether the OR Mapper was in the right place. Does an OR Mapper replace the Data Access Logic Components (DALCs)? Does an OR Mapper complement DALCs? Does one comprise the other? I had, and still have, no idea. So why is it there? Simply because I have one (Paul Wilson's ORMapper) and because I dislike SQL. Granted, they are not good reasons for an OR Mapper to be there, but I thought that if I put it in the diagram, it will mean that I later investigate its possible use in Charlie.
I was also concerned about the location of the modules in the Presentation layer. I see the modules working the same way as modules work in DotNetNuke, which I know to be based around the concept of ASP.NET User Controls. So, my initial thought was that my modules therefore belonged within the Presentation layer. But I knew this to be incorrect. A module such as a blog must coordinate presentation, business, and data access activities. I also wanted each module to be able to use its own data source. So, where do modules go?
I also noticed, with some embarrassment, that even though Charlie is to be a website framework, I had not included the websites themselves. They too need to span presentation, business, and data access concerns. So, where do the sites go?
To address the question of modules and sites, I came up with the following second draft.
Having drawn the second diagram, I evaluated it.
It was a poor design, and I knew it. Separating the application into three layers of separate concerns (presentation, business, and data access) is a proven technique. But separating the application along a second arbitrary axis (framework, sites, and modules) created a matrix that would complicate development, not simplify it.
Yet, I somehow had to come up with a way in which I can plug in new websites and new modules, all of which need to span all three layers of the application. How?
The first step towards answering this question involved recognising that plug-in modules and plug-in websites represent the same problem. That is, each plug-in type must span all three layers. Whatever design solved the problem for modules would solve the problem for websites, too. I need not address modules and websites separately.
I started drawing a new diagram that did not involve the horizontal split of framework, sites, and modules. I could see only one possible way of getting sites and modules into the architecture in such a way that they spanned all three layers, which I illustrated in the following diagram.
Having drawn the above diagram, I evaluated it. I’ll point out that the OR Maps are not necessarily the XML-based mapping rules common in OR Mappers. Rather, I saw them as likely being classes that took the properties of the assets of the module (such as the title, abstract, and body of an article asset) and created a DataTable or DataSet that could be passed to the Data Access Logic Components (DALCs). Admittedly, the above diagram does not include the DALCs, as I was concentrating on how the websites and modules could be incorporated into the architecture.
I felt that the above diagram was heading in the right direction. A module would comprise a presentation package of User Controls, images, stylesheets, and so on; a collection of assets and the logic that controls them; and classes that mapped back and forth between the object-oriented assets and data-centric DALCs. A website too would comprise a presentation package, a collection of assets and logic, and classes that mapped from the objects to the XML configuration files.
I then turned my attention to the security, logging, exception management, and messaging components. They looked somewhat ill-considered—just dumped into the business layer. It occurred to me that the security component would require its own collection of presentation pages (for the website owner to view and edit members and roles). Similarly, the exception management component would need its own collection of presentation pages (for the developer to view any problems). These components would also need to be able to store data. Clearly then, these components could be implemented in precisely the same way as the websites and modules.
Taking a new sheet of graph paper, I then drew the following diagram. I deliberately left out the DALCs, as I was not sure of where to place them. (Databases and data access are a real weakness in my developer skillset.)
Having drawn the above fourth diagram, I evaluated it.
I felt that I was really getting somewhere. It may yet become apparent that the above architecture is completely wrong, but having drawn it, I at least felt that it was taking shape.
I noticed that there was no difference between the modules and the components. In my mind I understood modules to be visible on the webpage (a blog module would show blog entries, a photo module would show photos), and components to have no visible aspect (except when in administration mode). But that distinction seemed a bit arbitrary, so I decided that all customizable components would be called modules.
I then attempted to add a bit more flexibility into the design, and came up with the following diagram.
Having drawn the fifth diagram, I realised that it was a mistake.
I had thought to add a bit more flexibility into the design by not requiring all modules to have a presentation package or to persist data. That was dumb. There is no point in module 3 exposing pages to accept user input if there is no way to store the choices made by the user. And there is little point in module 4 storing data that cannot then be seen.
I decided then that any component that could be customized would be called a module, and would include a presentation package and a persistence mechanism. Having made that decision, I flipped through Application Architecture for .NET: Designing Applications and Services to see whether it would help me to sort out the data access layer. This Patterns & Practices document did indeed help, and I arrived at the following design.
Having drawn the sixth diagram, I evaluated it.
I am fairly comfortable with this architecture. While it is not complete, it appears to provide a flexible system that will allow Charlie to achieve its feature set, which in turn will allow Charlie to meet its purpose, as stated in the elevator pitch.
The next step is to add detail to what is currently a very basic architectural view. Before I do that, I will use my next two blog entries to detail a couple of decisions that I have made along the way.
by Alister Jones | Next up: Why the Wonky Wheel? →
----
Post a Comment