the rasx() context

This .NET-2.0 project is reorganized for future enhancement. These are the new and improved separation of concerns:

• Data Transfer Contracts: currently they are used for Input only but can be used for output.
• Input Definitions: currently these classes (implementing data transfer contracts) support IXPathNavigable input.
• Output Definitions: what is in place now is a single static partial class for XPath-navigable output.
• Procedures: this area of concern contains static classes for Delete, Get, Insert, List and Update procedures—almost all of these return raw XML strings straight from the DBMS (via System.Data.Common). This “strange” design is possible based on the research documented in my note: “SQL Server 2005 PROBLEM: Using the ADO.NET DbCommand.ExecuteScalar() Method Truncates at 2033 Characters.”
• Resources: this refers to embedded Resource files—in this project these are parameterized t-SQL scripts. Of course something like LINQ to SQL can do all of this work “for me” but I would have to store these t-SQL scripts on the database server (which increases performance and security—and maintenance complexity).

All of these areas of concern are mediated by a façade, the CommandHandler class. Because it implements the Songhay.Data.ICommandHandler interface, it expects to return XPathDocument messages to an external caller.

My commitment to XPathDocument messages dates back to .NET 2.0. In our brave new LINQ-based world, we have the XDocument. Before these latest improvements, my “old” code was not in a position to easily move into this new world.

By taking the time (many hours over many days in a very hot summer room) to loosen up the coupling, I have more options:

• I can write a LINQ version that uses LINQ to XML and still uses the old System.Data.Common stuff.
• I can write a LINQ version that uses LINQ to XML and uses LINQ to SQL (or LINQ to Entities) exclusively. The problem with this is that I am almost sure that LINQ to SQL (or LINQ to Entities) does not aggressively and obviously eliminate what is there now under System.Data.Common.
• I can write a LINQ version that uses LINQ to XML and still uses the old System.Data.Common stuff—but I can insinuate LINQ to Entities where it is super-obviously appropriate (for example wherever I might be using ancient ADO.NET DataSet objects for procedures that require an in-memory database).

My previous note about LINQ to SQL takes some of the polish off the DBMS-access aspects of LINQ. So I am no longer peer-pressured (most of this pressure is imagined) into getting rid of System.Data.Common stuff because LINQ to SQL is “obviously” better. No, the real question is, ‘Does XDocument completely replace XPathDocument?’ Sadly, I can only trust me to answer this question.

A few random notes:

• Because XML is used for output there is no pressing need for output contracts. The great news is that such things can be added without violating the Open/Closed Principle too damn much.
• My use of ICommandHandler for a façade and a mediator looks like it can be replaced by a WCF service using named pipes. The problem with this is that I do not want to lose compatibility with Mono. Yes, kids… Mono.
• The most important task to do next is backup changes locally, add documentation to all public members and get the changes out to CodePlex.com. After this, what should be next are all the TODO items.

This entry was posted on Tuesday, September 8th, 2009 at 8:33 am and is filed under .NET related, Data Management Solutions, Design Diary, Digital Media Production, root. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.