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.
Tags: design patterns, framework, marklogic, mvc, xquery
December 8th, 2011 at 4:27 pm
[…] been an increasing amount of talk about MVC in XQuery, notably David Cassel’s great discussion and to an extent Kurt Cagle’s platform discussion that touched on forms interfaces. Lots of […]
March 2nd, 2012 at 1:51 am
I have written an a full stack Rails MVC framework called XQuerrail (squirrel) which solves many of the problems associated with building scalable MVC apps in MarkLogic or an XQuery database system. While everyone can build some semblance of a MVC framework. The true beauty of XQuerrail is that it actually can scaffold administrative interfaces to support /REST/XML/JSON Read + Write and a powerful templating language that makes composing web pages very simple. The project has been opensourced with no release as I am working on documentation, unit tests and features to move it to beta 1 (very much alpha at this point).
You can find the source here:
https://www.github.com/garyvidal/xquerrail
and the official site is http://www.xquerrail.com
March 2nd, 2012 at 7:03 am
Hey Gary. I know you’re aware of the framework that Paxton & I have been working with, now dubbed “roxy”; it will be in github in the near future. Our framework, in development for about six months and already used on several projects, also uses the MVC pattern. Roxy comes with deploy and unit testing components; supports XML, JSON, HTML and other response types; and comes with multiple application layouts. I’m sure we’ll each find ideas in the other’s work, to the benefit of those using either.
December 5th, 2016 at 8:20 am
Hi Gary, In the Framework you mentioned in the post, can you update the package in Git with instructions how to use this using Eclipse
December 5th, 2016 at 9:16 am
sivakesava, you’re much more likely to get a response by filing an issue on Github: https://github.com/garyvidal/xquerrail/issues