With the move away from traditional ASP development in favor of the ASP.NET platform, we've made a number of architectural leaps and bounds throughout the projects. While things like this are forever in a state of flux and evolution (especially with the looming ASP.NET 2.0 release), I truly believe that we have assembled a robust library of code and an architecture for sites moving forward. This Genesis framework takes the shape of two libraries, GSControls, and GSComponents, as well as a template site which we refer to as the Architecture Template. Together these reusable code libraries allow many Genesis projects to share a common codebase, and give us a great head start on new projects, eliminating the need to start an application completely from scratch.

Over the course of the next few blog entries, I will introduce you to the Genesis code framework, providing explanations for the decisions we've made, and providing a basic overview of the functionality each component part encompasses.

An Overview:

Loosely based on the wonderful framework set forth by the Community Server team, the Genesis Framework provides the following 3 key areas:

GSControls

Here you'll find any number of custom server controls that may be shared across all Genesis Applications. This include such things as

• BusyBox and HoverBox controls
• A number of specialized button controls
• Date Pickers, validators, etc.

Many of these, including the DatePicker and the Validators, are wrappers around 3rd party components, such as the Obout Calendar control, and the VAM validators.

GSControls also incorporates the Genesis Page Framework, which allows us to do a number of things, including assigning Javascript multiple functions to the OnLoad/OnBeforeUnload page events.

We also have the ability to allow "Skinning", in much the same manor as Community Server. This logic is all encompassed in the various GSControls classes, and allows us to build sites which are either directly skinnable now, or may be easily extended to support skinning in the future.

GSComponents

GSComponents provides a number of classes which are common to all Genesis projects, but do not display a user interface. Most notably, the GSConfig class serves as a base configuration reading class for any project. The GSComponents library also implements the classes necessary for the Provider Pattern. Most all Genesis web applications utilize the provider pattern in some way, and thus the classes are implemented here. In addition, a number of providers are included, such as

• An EmailProvider/QueuedEmailProvider which provides direct email support, or queued email support.
• A DocumentProvider/FtpDocumentProvider which allows us to save documents (docs, images, etc) locally, or to save them to an FTP server instead.

These providers allow us to program in a implementation agnostic manor these various features.

Architecture Template

The Architecture Template serves as a template project from which all new projects should be based. Like Community server, a Genesis project should have 3 main components:

• Controls, where all of the site specific controls are stored. This project references the GSControls project
• Components, where all of the site's business logic and components are kept. This project references the GSComponents project.
• Web, where the aspx/ascx files are stored. One thing that we make sure to do, is to make sure that this is *NOT* a Web Project.

We absolutely despise web projects for any number of reasons. Mainly, how you're tied so closely to IIS, and also how your code ends up in two locations: webroot & wherever your solution resides.

Instead of a web project, Web is simply a class library. Following the directions laid out on a number of sites, it's completely possible to have a fully functional, debuggable site in this manor. We love it.

There you have it. That's the basis for almost every new project coming out of Genesis. In fact, we like the code reuse so much, we've invested quite a bit of time back-porting some of our older ASP.NET applications to use this very framework.

I haven't described these in too much detail, I'll leave that for other posts. I'll also leave the .NET 2.0 discussion for another day, for that release includes a number of things that our code library has set out to solve (providers, skinning, etc). However, the concepts will remain the same:

We will keep adding things to the library, in an effort to keep code copying to an absolute minimum.

Dusty Davidson
Lead Software Developer