Design Decision Made

We have made a decision on how to structure the framework. That's what we're calling it now, a web application framework.

There will be a central framework that all pages will derive from. The framework will provide the lower end functionality; Security, Themes, Menus and Exception Handling. The framework doesn't really care much about the pages it is encapsulating, except that they impliment certain Interfaces and that they have a certain structure. As far as the functionality goes, the framework doesn't care what the page does.

Each page will contain 4 objects. The objects are simply aspx panels, but there will be either a custom control that provides that or a project template that will drive it. Pages are going to be uploaded to the server through a web interface and the framework will validate the page structure. I'll talk more on that at another time.

On the data side we have decided to go with a distributed model. One of the functions of the framework is to determine what data connection to use at a given instance. So, for example, let's say a page provides a discussion group. When the discussion group page loads it asks the framework what data connection do I use at this particular instance? The framework responds based on the page and the context of the user. Since this is multi-tenant a page is supposed to provide functionality to multiple users without collision.

So, we will have a central framework database. This database will only keep information that is relivant to itself. The only thing it knows about the other pages is what their URL is, what roles to grant access to what modules, and what dataconnection to use. All the rest of the functionality of a page points to child databases. This will give us maximum scalability (data wise), allows us to determine by client where the database resides, and provides us a security mechanism that completely seperates clients data from other clients.