Model Template View

After using Pyramid for a personal project, I’ve become a fan of Model Template View. The differences seem to me mostly a result of semantics and history because they both achieve a similar separation of concerns but in a slightly different way.

In Model Template View frameworks, a view takes the HTTP request as a parameter and returns a HTTP response. The view loads data from the models and passes it to the template. The template controls how the data is displayed. Nothing is really new as the definition for the view sounds very similar to a controller in MVC and the definition for a template sounds very similar to the view in MVC. While there is a subtle distinction, there isn’t any reason a controller couldn’t be implemented in the same way as the MTV’s view unless we really want to be nit picky about semantics.

The difference is in the MVC implementation that’s become standard. Construct a base controller class, create controllers by extending it, add actions, and the framework will route by invoking an action in the derived controller. MTV skips the base controller structure and simply invokes a function based upon the route. It avoids what I find to be the monolithic OO structure. It’s simpler to understand and easier to test. Instead of having to mimic the construction of the controller object and invoking the action, I can simply call the view function with a standard HTTP request parameter.

For someone unfamiliar with functional programming, it may seem like removing base controller class leads to problems with code reuse. Controllers typically have magic methods like before and after to run code that needs to be run on every action call. In an MTV framework, I would wrap the function with a new function containing the code for before, after, and so on (decorators in Python).