In Relation To

Back to home

Business logic in templates

Posted by    |      

Stephan Schmidt says that people don’t get the difference between business and UI logic:

People most of the time use business logic in their templates, be them JSP, Velocity or Rails. They confuse business logic and UI logic. Those are two different things.

As an example of something that should be avoided, Stephan gives the following code: 

<c:if test="${user.loggedIn && user.bookedProducts}">  
 // show menu  
</c:if>

Well, you can count me among those who don't get the difference. I don't see how it is clear that the expression in the code above is implementing business rather than user interface logic. In fact, it seems to me that distinguishing the exact boundaries of what constitutes the /user interface/ is in general more art than science.

In this particular example, it seems to be the && that Stephan objects to. If I'm reading him correctly, he would not have a problem with this: 

<c:if test="${user.loggedIn}">  
 // show menu  
</c:if>

or this: 

<c:if test="${user.bookedProducts}">  
 // show menu  
</c:if>

However, I don't see that the use of conjunction, a priori, is enough to turn something into business logic.

Any user interface depends upon attributes and operations of model objects. Sure, we /could/ introduce some intermediating layer to shield our user interface from a direct dependency upon our model, but this merely moves the dependency around; it does not eliminate the dependency, nor solve the question of exactly which logic belongs in which layer. What is unclear is the criteria for determining which logic must be implemented by the model, and which may be safely implemented in the user interface (or intermediating layer) code that uses the model.

We talk about business logic all the time, so you might think that this is some kind of well-defined notion, but as even Wikipedia admits,

Business logic is a non-technical term ... there exists no definition of business logic in any programming language specification or API, nor in any academic research ... it should be noted that business logic is a poorly-defined term which is used in several different ways by several different groups of people.

Nevertheless, Wikipedia goes ahead and defines the following scope for the term:

Business logic:
  • models real life business objects (such as accounts, loans, itineraries, and inventories)
  • prescribes how business objects interact with one another
  • enforces the routes and the methods by which business objects are accessed and updated

Stephan's code example is not defining a business object, nor an interaction between business objects, nor does it seem to me that it is enforc[ing] the routes and the methods by which business objects are accessed and updated.

So, assuming that this expression does not occur in multiple places in my templates, I would be inclined to leave the original code alone. It seems to me that the cost in complexity of introducing a new method (possibly a new object) to encapsulate this expression is simply not worth the effort, unless there is some additional concrete benefit.

On the other hand, if this same expression does pop up in multiple places, I would almost certainly encapsulate it in a method of some model object:

  1. in order to satisfy DRY, and
  2. to allow me to document (via the method name, or even JavaDoc) exactly what the expression represents; what is so /special/ about this expression that causes it to occur repeatedly.

So does that make me a defender of the use of (short) scriptlets in JSP, PHP or RHTML? Well, no. But my objection to the use of scriptlets has a different basis. What I find objectionable is the mixing of highly dissimilar languages and language paradigms in the same source file. I remain a fan of declarative user interface definition.

Back to top