Smart Views vs Model Facades

The Helium team hit a milestone last week: they demoed working pages, backed by a persistent store. It may sound pretty tame, but when you consider that none of us had seen Tapestry or Hibernate eight weeks ago, it's not bad.

We now have to face a difficult design decision. The current pages show everything to everyone, but the final system has to filter content according to user identity. For example, professors have to be able to see everything, but students must not be able to view each other's projects. Jason Montojo has designed and implemented an authorization module to decide whether user X can see thing Y. The question is, who should invoke that module, when, and where?

Since Tapestry is a Model-View-Controller , there are three places authorization decisions could be made: the model, the view, or the controller. We ruled out the controller right away: as in Struts and other frameworks [1], Tapestry's controller simply despatches from one application servlet to another.

In email, Howard Lewis Ship (Tapestry's inventor) recommended putting authorization decisions in our views: for each element X, the view would call the auth module to determine whether or not do display it.

In contrast, Irving Reid suggested putting a facade on top of our model classes. The facade class (or classes) would filter actual model content according to user identity, so that each view only saw the things it was supposed to display.

We've decided to go with the model facade, primarily because we think we're going to have lots of fine-grained authorization decisions to make, rather than a few coarse-grained ones. Smart views are probably appropriate for portals, in which large chunks of content are included or excluded as wholes, but it doesn't feel like the right solution when the "content" is as small as the individual links in a tree display.

The most interesting thing about this decision (for me, anyway) is that the issue isn't mentioned in any of the books I've read about web application frameworks. It appears to be yet another one of those "orphan" topics that everyone has to deal with, but no one bothers to document. I'd be very interested in pointers to MVC frameworks that have built-in support for authorization decisions, or to books or papers that analyze the problem.

[1] I was a little depressed to discover that both Tapestry and Struts are Apache projects. I appreciate open source's "let a hundred flowers bloom" philosophy, but the outcome is often too many projects that fall just short of the critical mass needed to become category killers. For example, if all the effort that has gone into Python many web frameworks had instead been put into one, we'd probably be building Helium in Python instead of Java.

comments powered by Disqus