Random Screenshot: A Solidified ASP.NET Server Design

This image represents the summary of the decisions made by me about how to design an ASP.NET Server application. These decisions are extremely important to me as it defines how my thoughts are able to function regarding this matter. In other words, without these decisions I am an empty set of hands blindly waiting for orders instead of taking initiative and the upper hand of pro-action. This image allows me to see my understanding of this matter.

Here are the strong words governing my understanding:

• Post Data Handler—the Server will process RESTful post data, strings that are usually well-formed XML. This means that the client/cloud will prepare and send XML strings to the server. This is utterly ridiculous to “mainstream” programmers as they would rather have JSON or a SOAP wrapper taking care of them. So you can understand why I am little self-conscious about making this decision—but at the same time quite indignant and successful with this very flexible, server-agnostic approach. (Hint: in ASP.NET, read XML posts with HttpContext.Request.InputStream—you can also do the equivalent in PHP and surely in some Java container.)
• Response Builder—the Server will build a response using defined responses. This promotes maintainability and code reuse.
• Request Bag—the Server defines all incoming requests. This ‘bag’ captures all incoming query strings into a plain-old object. This promotes maintainability and contributes (somewhat) to security. This decision is similar to the reasons why database server designers use stored procedures and/or parameterized queries.
• Server—you can see this strong word in today’s image in the word QuizStoryboardServer. So the decision here is that the Server (which extends HttpApplication) always has a prefix indicating the specific purpose of the application. In today’s case, the specific purpose (which has nothing to do with you) is serving up something I call a ‘Quiz Storyboard.’
• Command—like Server, you can see this strong word with a prefix in StoryboardCommand. This represents another firm decision that a Server uses an enumeration of commands (an enum). The type StoryboardCommand is an enum defining the specific commands that this Server will respond to without exceptions (that is, without throwing an error message). The Server finds these commands in the Request Bag (Hint: the Enum.Parse() method turns a string (from the Request Bag) into an enum). In this particular case, StoryboardCommand.PassToDataLayer is the default Server command—so ‘passing to the data layer’ is what the Server does when it cannot find the requested command (see below). My data layers, by the way, also use Command enumerations. I have been struggling for the last two weeks building this Quiz Storyboard Server. I have missed the deadline by three days. So I am totally pissed off. But this is cool: In the conventional App_Data folder you can see in the image two XML configuration files, QuizStoryboard.xml and TemplateDictionary.xml. Of course the Quiz Storyboard Server handles QuizStoryboard.xml. This file, for example, allows the Quiz Storyboard Server to gain access to the “data layer” through an interface. But the TemplateDictionary.xml file is completely generic.

The template dictionary maps Command names to XSL templates. Yes, that’s right: XSL templates. Look in the room full of .NET developers you may be in right now and I bet you can’t find more than one XSLT dude—most likely zero. XSLT allows me to handle the problem of data binding to a “view”—the V in Model View Controller in a Client-agnostic way. All I require is that the Client (another strong word) can send and receive XML messages (a stupid block of XHTML is an ‘XML message’ folks). As of today, these views are called by my implementation of the YUI library via AJAX.

It should be clear why I am likely to turn down a development position at your local, do-right company. Of course you don’t care but I prefer to use REST in a .NET world. I prefer to use XML in a .NET world. I prefer to use XSLT in a .NET world. This approach reduces vendor lock-in significantly and increases flexibility. (Most Microsoft shop heads—especially those dating back to the 1990s—are locked in to something horribly limiting and are arrogantly in denial.) And, no, Rocky Lhotka did not waste years of his life trying to master the frustration of Microsoft-approved data binding. Unless, of course, you call commanding six-figures year over year “frustration.”

In my Microsoft world, I can take one of my clients and point it at a completely different (non-Microsoft) server. I can take one of my servers and send messages to a completely different (non-Microsoft) client. So my preferences exist not because I am “smart” but because I do not have the luxury of predicting through political job security what technology I will be using. And I do not have the “privilege” of being responsible for raising the earnings of a software tooling company. XML and REST are about survival.

Only in the last two or three years has Microsoft revealed itself to be interested in what I am doing here. You can see this interest in ADO.NET Data Services, ASP.NET MVC Framework, XAML and other stuff. Ditto for Adobe, with E4X support in Flex. I blame Scott Guthrie for providing leadership in this new direction and I commend him for his efforts.

rasx()