Eitan Suez's Blog

MVC without leaks implies generic VC

How many times have we heard or preached (or both) the important lesson of not having our business logic "leak" into the client tier. Each time we hear it, we nod our heads and say "how true," and get serious for a moment.

The idea of logic leaks applies to other aspects of development, not just the client tier. For example, the Hibernate project is very concerned about not leaking persistence issues to other application tiers.

As I was thinking about this notion of business logic leakage, a very interesting thought came to me. Say for example that we define a business object, maybe a Customer. Furthermore, let's say we define a number of fields on this object: name, date of birth, etc.. The minute we put down in our text editor the lines:

<caption>Name:</caption>
<input type="text" name="name" />

..is the minute we've crossed the line; we have violated the DRY principle. We have just leaked business logic into our view. From now on, if we rename the field, we must do it in two places: in the model and in the view.

Now, imagine being in the process of developing an application consisting of a dozen business objects, each with a half dozen fields. Model changes are going to occur. They're going to imply making changes in more than one place.

Given this, it's no wonder that resistance to change grows as a project gets larger. Yet business change is inevitable. People talk about the high cost of building software. It's no wonder the cost is high if we have to manually make each change twice. Not only is it more work but also error-prone. The essence of DRY is eliminating that duplication.

So, having provided a context, I can finally describe this small epiphany I have had in a short sentence:

If we're going to have a model-view-controller system without business logic leaking into the view, then we must construct generic views and controllers.

What does that mean? Take for example, the CRUD scaffold generators in Rails. The code duplication is still there but at least the duplication is automated. Admittedly not bad for a first pass.

The other interesting tidbit that sort of "falls out" of this small thought exercise is:

GUI is plumbing

I've been saying this for a couple of years now but it is still my hope that some day everyone will have good GUI plumbing for their software applications.

Comments

• What we found is that the 'model' in the client not necessarily has very much in common with the actual domain objects or the model on the server.

  
  So we define a seperate client-side model for the MVC system which can be generated from the view (and not vice-versa, which is the most common approach). Client-logic, client-constraints, ... all run against these models. The thing that has to be done of course is to finally map client- and server-side models. But there is only one place to do that.

  
  Generic views are the most easy way to go, but from the users viewpoint, they suck! IMHO parts of the system design has to start with the GUI and let function follow the form.

  Posted by: herkules on May 03, 2006 at 12:21 AM

• very interesting. sounds like a lot of work though. so, yes, the generic views most people know about today do indeed suck. but here's my question: do they have to? think of how much work could be discarded if they didn't. here are some screenshots of a demo application whose gui is completely generic. what do you think?

  Posted by: eitan on May 03, 2006 at 07:40 AM

This work is licensed under a Creative Commons License.