Random Screenshot: the Songhay System Data Access Layer
Sometimes I will just sit there for many minutes thinking of the name of something. The name has to feel strong to me. It has to cohere with other names for fluency. My extensive background as a poet and my respect for my ancestors actually help quite a bit. But don’t “fall for” my “rhetoric” just listen to Jeffrey Snover talk about the importance of naming (conventions) in PowerShell.
So the picture at left shows me the satisfying results of this path of strong words:
First there is the Data of the Web schema. It is important to highlight that the Songhay System has a database schema called “Web.” This may help to clarify that the words DataAccess and DataProcedure are for the Web schema. The implication here is that the two primary concerns of a schema is its access “layer” and its procedures. There is also the DataContext which comes for free from Microsoft’s new LINQ to SQL. According to Microsoft’s naming conventions, the data context for the Web schema is called WebDataContext.
The names that appear under the DataProcedure are quite obvious to anyone working with databases. Many of my CRUD procedures use LINQ to XML extensively. What are not so obvious (to me) are the names shown under DataAccess. It took me a while to be satisfied (today) with naming the concerns under DataAccess using two strong words: Handler and Builder.
Here in the rasx() context, a ‘Handler’ in a data access layer responds to input from ‘the outside world.’ It follows that the CommandHandler responds to requests from the cloud (or the console). The CommandHandler ‘knows’ a finite number of requests (commands) which are stored in an enum. The CommandHandler stands as the façade for the entire data access layer. It calls upon a combination of PostDataHandler and ResponseBuilder to ‘handle’ commands (requests).
To cohere, one can say that the CommandHandler builds a response (in the ResponseBuilder) based on the name of the command it understands and any associated XML message (post data) it can validate and process (in the PostDataHandler). Notice here that there is no mention of “robust” security innovations. On my small scale, I get by with HTTPS and/or NTLM-based crap.
This primitive RESTafarian façade architecture was built before I became aware of the ADO.NET Data Services technical preview at Microsoft. I look forward to finding (yet again) that Microsoft can build a solution for my problem that meets (and exceeds) my expectations. But for now, based on my research (watching and listening to Pablo Castro at MIX08), I need to keep going for my solution. The certainty here is that the lion’s of my custom code is for the Web schema and is quite safe from being replaced with a magic bullet from any reliable third party.