The Impedance Mismatch is Our Fault

“We made this problem, we invented it.” — Stuart Halloway

In The Impedance Mismatch is Our Fault, Stuart Halloway presents a compelling approach to solving the impedance mismatch problem by programming with values. I often cite this presentation as being one of the most influential I have ever seen.

The Home Game

Therefore, I thought it would be interesting to solve the problem for an existing system without modifying the underlying storage whatsoever. I also didn’t want to write thousands of lines of Data Access Layer (DAL) code, or use an Object Relational Mapper (ORM).

Instead, I decided to simplify the problem itself, and solve for location and programmability. The single largest problem we face when working with the database is that it is “over there”. How are we supposed to make informed decisions about our data when we can only access a subset of it at any one time? We can’t. Therefore, we need to go to where our data is — the database. We need to get over our aversion to stored procedures and start writing our SQL where it is meant to be written. This should make sense — where else do you write programs by concatenating strings together, only to send them over the network to be executed by a different application?

I am absolutely not advocating that we should write our business logic in stored procedures, but we should at least write our data manipulation code in them. This solves for both location and programmability — we are where our data is, and we have a capable, if not expressive, programming language to manipulate it with.

However, we still need some way of getting our data to our stored procedure. Utilising multiple parameters would mean writing a lot of DAL code and an explosion of table-valued parameter types — this doesn’t scale well. Instead, we should serialise our aggregate using JSON or XML, and send it as a message in a single parameter. This shouldn’t be new to us — it’s messaging 101. We almost always do this when sending data over the network, so why should sending data over the network to the database be any different?

Once we receive the message in our stored procedure, we can shred and map it to our existing tables. Dealing with JSON or XML in the database is often far more concise than it is in application code, and also tends to be less prone to error.

It’s a similar story when it comes to returning data back to the application. Instead of returning rows of data, we can project a JSON or XML document. As Halloway notes, “the document is the beautiful end result of a query”.

Data Access Layer

XML Club

Performance Matters

It must also be taken into account that you may be making savings on roundtrips to the database. For those of us not using ORM’s, the number of roundtrips to the database can be eye-watering. This can be important when working in the cloud, or anywhere where the latency between the application and the database isn’t optimal.

Final Thoughts

Software Developer in Northampton, United Kingdom |