The Web System
In explaining the Simplicity of Casting, I used the analogy of a software system comprising Kids, a Bus, and a Program. The Kids are the little tykes who get moved around, the Bus is the method of moving the Kids around, and the Program creates a little pretend world where the Bus transports the Kids between Home, School, and PerformanceSchool.
Well, the Web System for Charlie is very similar to this little eco-system.
First, the Kid objects become the Entity objects in Charlie. (Read about the Entity System for an overview of the Entity object.)
Second, the Bus object becomes the WebContext object. The role of this WebContext object is to transport Entities around the system, just as the Bus transported Kids around.
Finally, the Program becomes the WebApplication. Its job is to create the little runtime world where the WebContext object transports Entity objects around, just as the Program created the little runtime world where the Bus transports Kids around.
The updated architectural diagram now looks as follows (click to zoom in):
The WebApplication object has a lifetime that spans from the moment a Request is received to the moment the Response is sent. The WebContext object has the same lifetime, but whereas the WebApplication object is fixed in place (it does not get passed around), the WebContext object gets passed along as the WebApplication processes the incoming request and prepares the outgoing response.
Those of you who know ASP.NET well will recognise that this is precisely how ASP.NET itself works, using the HttpApplication and HttpContext objects. And those of you who do not yet recognise this structure may wish to read the ASP.NET Application Life Cycle Overview.
It has been a deliberate decision that the Charlie Runtime layer will stay very close to the ASP.NET runtime. Microsoft has put in a huge amount of work making the ASP.NET system simple, flexible, and powerful. It seems prudent then to build upon the intrinsic ASP.NET system and stay faithful to its design, rather than design a new system with its own kinks and curls. With that in mind, Charlie has a WebRequest object that mimics the instrinsic HttpRequest object, and a WebResponse object that mimics the instrinsic HttpResponse object. They are attached to and move with the WebContext object, just as the HttpRequest and HttpResponse objects are attached to the HttpContext object.
Charlie also provides a WebModule class that allows Plugins to register themselves with the WebApplication, in precisely the same way that IHttpModule classes can register themselves with the HttpApplication class. Charlie also provides a base WebHandler class that ultimately handles the incoming request, which is exactly what the IHttpHandler interface defines. Finally, Charlie also provides a WebFilter class that allows Plugins to filter the final response stream, which matches the functionality of the HttpResponse.Filter property.
I have named this the Web System, for what must be an obvious reason. I then decided that whereas the Interface, Controller, Business, Persistence, and Services layers would have their own folders and own namespaces within Charlie’s Visual Studio solution, the Runtime layer would not be within a folder, but would reside at the root level of the Project. As a way of documenting this decision, and to provide a skeletal version of this Web System, I created empty classes for each of the Web elements described above.
by Alister Jones | Next up: The Plugin Manager →
----
Post a Comment