Models in XQueryAuthor: Dave Cassel | Category: Software Development
At MarkLogic, I work on a team that is charged with building Proof-of-Concept systems quickly and building them well enough that the developers who take over later will have a good starting point. I’d like to talk more about the framework that we’ve built to help us with those goals in future posts, but for today, I’ll limit myself to the fact that this framework uses MVC as the major design pattern.
Yes, we’re talking about Model-View-Controller. I’ve had a number of conversations with people about whether MVC makes sense in an XQuery world, and I wanted to share my reasons for thinking it does.
The conversation typically centers on the Model part of MVC. The argument against MVC in XQuery points out that a big part of the Model’s job is to get rid of the impedance mismatch between the way data is stored (perhaps rows and columns in a relational database) and the way it is used (perhaps Java objects). In XQuery, data is both stored and used in XML, so there is no mismatch, ergo a Model is overkill. That’s a valid point as far as it goes — after all, that is one of the benefits of working with XQuery in general and MarkLogic in particular.
When we started with our framework, we took a VC approach — we used Views to separate out the presentation logic, and we used Controllers to handle request inputs. However, we still used library modules to do the work of taking those request inputs and turning them into some data to present. We wanted to isolate that logic so that we could write unit tests. Before long, we recognized that we were, in fact, building Models.
So what role does a model play in XQuery? A simpler one. Once you leave the impedance mismatch problem behind, the benefit you are left with is encapsulation. Many of our applications need functions to register, log in, and log out users, along with updating passwords and identifying the current user. Each of these is a function that we store together in a library module, which we write unit tests for and can easily pull out of one project and put into another. That’s our user model. Likewise, many applications have some central concepts to them that lend themselves to building a model, even though there is no corresponding table, as we would have in the relational world.
Yes, this is a thinner version of how people think of a Model in the relational world. But there are benefits to having divisions between the parts of your application, and MVC is an approach that is familiar and (when used properly) has been useful.