So novella has been out for a week or so, and so far the reaction has been quite positive (yea!). A few of the people who are getting their hands dirty have been asking me questions about the architecture and how everything works.

So to help them and the others who are too shy to ask, here is a detailed look at the various layers that make novella tick. Before I begin, I should note that if you just want to use novella, you don’t need to know any of this. However, if you are taking things apart or you just like to know what does what, this might help.

Also, if you are a relatively new ASP.Net developer who doesn’t care at all about novella, this architecture is useful for building all sorts of sites, and is a good learning tool. I have used this architecture in one form or another on all the sites and desktop applications (with some tweaking) that I have built in the last year or so.

Lets get started.

3 Layer Bean Dip
The architecture behind novella is basically your standard 3-tier. If you are into design patterns, then you may be interested to know that the architecture is a mix of the Command and Facade pattern. If what I just said doesn’t make a lick of sense, no worries, it will all click in a bit.

First Floor: UI
The UI Layer is definitely the biggest, but it actually has the “easiest” job. It performs 3 functions.

1. Data Collection
2. Data Validation
3. UI Maintenance

The first function is Data Collection. This is exactly what it sounds like…capturing the input from the textboxes, dropdowns, and other controls. Next we have Data Validation. The purpose of this is to make sure that none of the data that gets back to the server is funky…i.e. a valid email address, or making sure that every block has a name. Finally, there is UI Maintenance. In the world of an ajax webpage, this is definitely where most of the time is spent. UI Maintenance is changing the interface based on what the user is doing. For instance, when you update a block a little blob fades in and tells the user that the update was successful. This would fall under the category of UI Maintenance.

So let start an example…Creating a new block.

On the page CreateBlock.aspx you can see all the controls that are needed to create a new block: a textbox for the name, and a textarea for the actual markup. When the user is done they click the “Save Block” button. This kicks off the data collection piece. In this case the system calls a javascript method ManualCreateBlock().

From here you can see that the app is collecting the data (i.e. name and markup), then checking to see that it is valid (i.e. making sure the block has a name and that it isn’t a duplicate) and then passing it back to the server. In the AddBlock method on the server all the data is packed up into a nice object and given to the Command.

Once the save is complete we do a little UI maintenance and tell the user that the save was successful.

Now it is time to go behind the curtain.

Second Floor: Command
The Command’s job is to take the data from the UI and prepare it to be stored. In novella’s case the data is prepared to go into the database, but in other applications I have used the command layer to put the data into Word documents, XML, etc. Once the data is processed, the command makes sure that it is ready for the UI to use. Most of the time this isn’t necessary (the data is already ready), but if you are doing stuff with serialization and the like, then the command might get a lot busier. In the case of novella, the command is quick and easy.

Lets continue with the example I started earlier.

As part of the UI layer the system bundled up all the data into a nice object called UIData.BlockData. This is a custom object I made that mirrors all the fields that make up a block in the database. The UI calls a method UICommand.AddBlock(). This method takes the object I need as a parameter and gets all the information ready to move to the database. In this case I build up a list of parameters to be used in the “dbsp_AddBlock” stored procedure.

Once the data is loaded into the parameter list its time to call the framework.

Third Floor: The Framework
Here is where the real work happens (as a sidenote…if you want to make your life a whole lot easier when starting a new ASP.NET website with a SQL Server backend, copy the code UIFramework first thing…there is just a ton of useful code here).

The framework’s job is to connect to the database, run the stored procedure, get the data back into an object (when calling a select query) and give it back to the command.

To finish the example, the command called a method RunInsertQuery and passed us the name of the stored proc and a list of parameters. The framework takes this data, opens up a Sql connection, passes along the parameters, and executes it. Next, the system returns an output parameter so the UI can know which block was just added. Finally, the connections are cleaned up so the database doesn’t hold it open any longer than it has to.

So there you have it…the novella framework. Its pretty simple, flexible, and outside of novella works well with all sorts of different types of sites. The only thing this version is missing is transaction support. I have that built into some of the other frameworks that I have built, but novella didn’t need it so I figured I would slim it down a bit.

I hope this in depth look at the various layers is helpful as you take novella and mold it to your own purposes, or even just as a learning tool. If you run into any problems, shoot me an email at david at creativeui dot com and let me know how I can help.