Fog Creek Software
Discussion Board




Welcome! and rules

Joel on Software

Input on suggested ASP.NET architecture

I am a semi-experienced .NET-developer currently working on a sort of portal software. It is simply my companys Intranet that we are using internally and also have sold (dear god make it stop) to external customers. This Intranet was developed by very inexperienced developers in ASP and some VB6. As you can imagine it is not exactly of-the-shelf-software that you can easily install at a client, nor is it by any measure bug free. Internally, it works fine, but add some changes and it becomes a mess.

It's main features are a simple content management part, where anyone can write articles etc and publish on the Intranet, either directly if they have sufficient access or to an editor that can in turn publish it. Other features include a small file archive, photo album, employee listings and a very simple calendar for booking company and group-wide meetings.

What we would want is of course for all of this to be extensible in the simplest possible way, so that if we actually sell it to a client, we can change what we have easily and add new features in a painless way. My idea for accomplishing this is what this is all about.

First, we need menus. The idea is that a "menu" basically can do two things, have children in the form of more menu objects and point to a specific "component". These components are the core of the system. One component could for instance be "ArticleLister" or "PersonLister". In the database I have three tables (actually more, but for this discussion that will do), Menu, Component and ComponentClass.

Menu has three fields, ID, ParentID and ComponentID. Component only has two fields, ComponentID and ComponentClassID. ComponentClass, of course, is the interesting one. There you have ComponentClassID, ClassName and ConfiguratorClassName.

The system works like this: A user clicks on an item in the menu. This raises an event, obviously, that I handle in a page called index.aspx. The eventhandler for that event calls a method in a custom webcontrol in index.aspx called ComponentLoader. The method is of course called LoadComponent and takes the ID for the component to load. The ComponentLoader then gets the class name from the database, uses Reflection to load the correct assembly, get a specific type, identify the correct constructor, etc etc, and calls the constructor Component(ComponentID). This constructor then loads whatever settings apply to this component and then it does its work. The nice part is that neither menu, index or componentloader knows in advance what specific componentclass it is loading, they all inherit from a supertype called Component.

The Administration Interface is going to be implemented as a Component that loads the Configurator for a specific Component. The Configurator will simply be yet another webcontrol that exposes an interface for changing settings for a specific Component.

All of this makes the process of actually adding say, a ForumComponent very easy. You just inherit Component, write a constructor that takes the ID, write a Configurator, add these classnames to the database and hey, presto! you are set to go.

I would love some of your input on this approach, is it sound or crazy?

Tommie Nygren
Wednesday, March 19, 2003

*  Recent Topics

*  Fog Creek Home