Random thoughts (RSS)

Random brain dumps of information that probably have no real value anywhere within the universe

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>

Maybe its just personal preference, but I don’t like to see XML beyond the scope of my data layer. IMO, the data layer is not limited to relational data concerns. It should also handle XML, File IO (if applicable), or any other means of getting and persisting data. Regardless if this data is persisted in a DB or acquired from a service. The business layer should expose common reusable business objects (or business entities, or domain entities, or whatever you like to call them – even DataSets if that’s your cup of tea) The important thing is that the XML data is mapped to your application domain business model somewhere between Business Layer and the Data Layer, but definitely not in the UI/Presentation Layer. Perhaps if we give the Data Layer a new cool name like the XDAL it would become more obvious?

Rocky at the PhillyDotNet user group

Well, I did in deed make the trek to Philly .Net user group on Wednesday. I thought I gave myself plenty of time, but it’s amazing what a inch or two of snow can do for traffic back ups. The last 30 miles of the trip took me almost 3 hours! I planed on getting down in time to grab a bite to eat and be there for the 5:30 PM start time. I ended up getting there about 15 minutes into Rocky’s scheduled 7:00 PM start! This sucked.

The venue was pretty cool (once I made it inside!) I wasn’t exactly sure where in the building the conference center was going to be located, so I drove past the first entrance to the parking garage in hopes to get a glimpse of a sign or something that specifically said “here it is”, thinking that I could just drive back to the garage entrance I passed if it was the correct one. Well a few hundred feet after going past the entrance to the garage (remember, it was snowing, the wipers where going, etc), I felt a little bump in the road under the snow as I made it up onto a walkway from the garage to the conference center doorway. And low and behold, as I sit on a walkway in my Chevy Suburban (thinking maybe I'm in a place I shouldn't be), I’m looking in through the front doors at Rocky standing there speaking, arms up in the air like a giant (physically and metaphysically) with two huge screens behind him displaying “Data != Objects”. I knew I had arrived ;-)

The session was a lot of fun. I’ve been a Rocky fan for years, so there was really nothing new I heard him say or do here. But, it was cool to see and here him speak it all in person. There was a sense of humor side, that you don’t always realize when your reading things here, or here or here. For example, “…the UI Guy’s job just sucks anyway…”, well I guess you had to understand the context and hear it in person to get the chuckle.

So, the driving sucked, I spent way too much time in my car, but it was real cool to meet Rocky. Don’t know if I’ll try to make the trek down again, unless there is some pretty compelling reason. I guess I’ll stick to more local user group meetings, and lobby that we can get some giants to come by too.

Off topic – Why I hate ordering Sandwiches From Subway

OK, this is a bit off topic and pretty random, but for what its worth, I really hate ordering sandwiches for a group of people from Subway. My frustration usually begins around the time an eager clerk first asks, “what kind of roll(s) do you want”.

Generally when I draw the shortest straw and end up being the runner for sandwiches, the process begins by me asking everybody what they want. I end up with a list that might look something like this:

  • John: 12” Turkey, with cheese, mayo, lettuce and tomato, on a white roll
  • Bill: 6” Ham, no cheese, Italian dressing, all veggies on an Italian roll
  • Jill: 6” Turkey, cheese, on a Parmesan Italian roll, no dressing, lettuce, tomato, olives
  • Sally: 6” Italian Mix, cheese Italian dressing, all veggies on a Wheat roll
  • me: 12” Chicken Teriyaki, Italian roll, sweet onion dressing, all veggies (except hot peppers)

So, I walk up to the counter with my list in hand, and the clerk says “What kind of rolls can I get you?” Do you see the problem yet? Am I the only person in the world that thinks this is just plain wrong, or at least difficult from the customer’s perspective? Sure, it makes sense from the perspective of the Subway clerks to work in an assembly line like fashion, first get the rolls, then the cheese (where needed) then the meats, then the veggies, dressing, etc. But shouldn’t that translation from what I want to what they need be their problem, and not mine as a customer.

When I am placing my order I’m thinking what kind of subs I want for each person. I’m not thinking that I need 2 - 6” Italian rolls, 1 - 12” Italian roll, 1 - 6” Wheat roll and 1 – 12” White roll. Besides, do I say 2 – 6” Italian rolls and 1 – 12” Italian roll, or when I’m at the roll ordering point, do I just say 2 – 12” Italian rolls, and then straighten out the finer detail that one of those 12”ers is really 2 – 6” separate sandwiches when we get to the topping questions.

The problem only gets worse after we deal with the rolls. Because then the next question is “ do any of these have cheese”. Well, lets see, looking at my list, the 12” Turkey has cheese, so there is one yes to for cheese on the 12” white. The 6” Ham has no cheese, the 6” Turkey has cheese, so yes to cheese on one of the 6” Italian rolls, but not the other (we’ll need to make sure I keep track of which is which later on when I’m asked the meat questions.) The 6” Italian mix has cheese so, yes to cheese on the 6” wheat roll. The Chicken Teriyaki has no cheese, so no to cheese on the 12” Italian roll.

Now onto more fun, the meats. The clerk (sometimes the next clerk in the assembly line depending on how busy they are) asks, "what kind of meats do you want on these." Well let’s see: I need a 12” Turkey on white with cheese, so if you have a 12” White with cheese there, then that is the Turkey. I need a 6” Ham on an Italian roll without cheese, so if you have a 6” Italian roll without cheese, then that one is going to be a Ham. I need a 6” Turkey with cheese on an Itailian roll, so if you have an Italian roll there with cheese on it, then make that the Turkey… and so on and so on.

Why, oh why, can’t I just tell you what I want and be done with it. Maybe the first clerk could punch my order into a program that then sorts and orders each of the individual sandwich components for each of the individual assembly line clerks. Or maybe you can just be old fashion and write my order down, and then determine for yourself the quantities of each of the individual components.

Subway, if you don’t have a sandwich order component sorter program, I would be happy to write one for you. Just email me at scottpstewart@NOSPAM_hotmail.com. I would be happy to help you out in return for a lifetime supply of sandwiches. ;-)

Jarred, does it need to be this tough for a customer to simply order a few sandwiches?