Scott Stewart

DataLayer lessons never really learned / attack of the embedded XPaths

Some lessons are never really learned. For years now, we have all looked at legacy code and scoffed at how other developers didn’t follow good layering practices. We shutter at the sight of data access code embedded in presentation code. We all know the reasons why good layering makes sense; maintainability, extensibility, re-use, team work efforts, debug efforts, code readability etc. We have all bought into the idea of using at least 3 layers in most business applications; presentation, business, and data access.

However, it seems that we haven’t really learned anything from all these layering exercises. Yeah, most people seem to follow some form of layering when it comes to working with relational data, but I’m not sure the reasons why layers are important have really sunk in. Because, in many ways, there are similarities with the way XML usage is creeping into code layers that are simply being ignored. I see the same mistakes being repeated today with XML data access that we made yesterday with relational data access. It’s seen in code samples online, at work and all around us. For example, I’m seeing XPath statements against domain data being written in presentation code, and something about the lure of XML makes it seem OK. I’m sure the people writing SQL in the presentation layers years ago felt the same way about the lure of ADO. Personally, I don’t think XPath statements against domain data have any more right being in presentation layers then SQL statements did a few years ago. Code like this makes me cringe:

Textbox1.Text = doc.SelectSingleNode(“//authors/author[@ID=” & ID & “]/firstName”).Value

This code violates the principals of layering that we’ve all learned are important when it comes to separating relational data access, but we seem to be forgetting about this with XML data access:

• Maintainability – sorry, but Xpaths throughout UI/Presentation code is not my idea of maintainable.
• Extensibility and Re-use – if the same XPath is written on a number of different UI pages, then we really aren’t thinking about re-use
• Team work – XPath statements coded directly in UI code means there is really no good abstraction of a business layer. It couples UI work with Data Layer work, and therefore causes Business Layer work to be embedded at the same time. This leaves little room for team efforts if all the layers are intertwined together.
• Debug/code readability – see first bullet in this list, but change the word “maintainable” with the word “readable”

One comment I seem to commonly hear when I talk about this to others is that my thoughts are slightly misguided because unlike relation data access, XML has the magic of XSLT. And well, even though it might not be great to have all these Xpaths in every layer of our code, at least if something should change with the underlying XML structure, we could always just apply an XSLT and get back to a point where everything is good. I think this is a lame attempt to justify bad software development decisions. I’m not arguing the XSLT point; I’m arguing its attempt to justify XPath usage in presentation layer code. After all, as bad as in line sql statements were, <insertTongueInCheak>we could have always solved the issues that came up when relational data schema changed by simply creating a SQL View that mirrored the old schema. Therefore, our old in line sql would still work even if the DB schema changes </insertTongueInCheak>