Redesigning My XML-over-HTTP Data Access Layer for LINQ

To people firmly entrenched in the world of SOAP Web Services, a Java-centric, IBM-style SOA architecture—one big-ass server for multi-million requests per minute, my data access layer is utterly appalling—humorous even. I guess I’m lucky because I am unable to understand just how appalling it is. I was even crazy enough to write about (pieces of it) on my green-colored company web site—“Songhay.NET: An Overview of the Songhay Data Namespace.”

One of the craziest bits in the Songhay Data Namespace is a strategy in the form of ICommandHandler. This ‘Command Handler’ is frighteningly biased toward XML over HTTP scenarios. Using XML over HTTP (instead of SOAP XML) is like saying “I’m unemployed” to the Java Posse (just kidding guys). It’s like saying “I am complete idiot” to the architects of WS-Security (not really kidding here). So, now that you know what you are dealing with, here is the existing scenario (from the cloud into the data layer):

• A strange, wild XML message arrives at the façade using the ICommandHandler strategy. The message could be a string, a navigable document (or any other type for that matter) stored in the DataCommandInput.PostData property.
• The incoming post data is validated. My preference is to make a few XPath assertions against a navigable document.
• The validated data might be parsed into a parameter array that will be used with a parameterized SQL string. (My Songhay.Data.Common namespace is designed to handle this.)Now more crazy stuff: before LINQ was released I wrote SQL queries in text files and stored them as resources to be compiled in my data access assembly. This must be more stupidity for those who are comfortable with using stored procedures. But those people are likely writing a set of procedures for one big-ass system—their database is more likely to be huge and unique. In my little world, my databases are numerous, “small” (less than one million rows) and they have the same schema. So, for the sake of maintainability (over performance), it is better (for me) to have parameterized procedures compiled in the code so it can be reused for different databases of the same schema.

What LINQ to XML does for me is eliminate the need to write SQL statements to be compiled in an assembly. This is actually crazy. Implied here is something very daring: LINQ can replace all of the functionality I need in Transact SQL for SQL 2005—even the great, new XML functionality in SQL Server 2005. Here are some examples of this great functionality (from my notes):

• “SQL Server 2005 t-SQL: Basic XQuery Example”

• “SQL Server 2005 t-SQL: Flippant Remarks about Using XPath Assertions Instead of XML Schema”

• “SQL Server 2005 t-SQL: The Use of the nodes() Method for XML Types”

• Now here are my new LINQ notes:

• “LINQ to XML: Using System.Linq.Enumerable to Generate XML; Code from Mike Taulty, Microsoft UK”

• “LINQ to XML: Generating XML with a Custom Namespace; System.Xml.Linq”

• “LINQ to XML: Two Ways of Generating the xml:space Attribute”This new work promises a few things:

• I will never have to work with DataSet objects again (unless I have the burden of taking some job in a legacy-mired .NET shop).

• All of my cute ways of generating XML in transact SQL will be replaced by LINQ to XML (System.Xml.Linq). This promises to be a clear, simple, powerful technological victory by Microsoft. No cheating. No politics. These victories are rare and should not be underappreciated.

• A new design with LINQ will push my ICommandHandler façade into further isolation (probably into its own assembly). This allows me to improve upon (or simply unplug) my crazy code.The acceptance of LINQ in my life has huge ramifications. Just for starters, I am willing to build a Microsoft-based ‘data server’ in the cloud (instead of the offline design I have now) instead of something on Linux simply because I am convinced that a LINQ-based data access world is easer to maintain that any other options I have seen. In order to save my time, I am even willing to pay a premium for this efficiency instead of struggling with something Miguel de Icaza and his posse puts together years later with Mono and MonoDevelop, an IDE, by the way, that is not guaranteed to work on my non-OpenSUSE flavor of GTK.

rasx()