Today is a good day to code

Why Separate Business Logic From Display Code – Is That a Trick Question?

Posted: December 31st, 1969 | Author: | Filed under: ColdFusion, Programming, Uncategorized | Tags: , | No Comments »

Why Separate Business Logic From Display Code – Is That a Trick Question?

Picture of Irv Owens Web DeveloperI was perusing the web the other day when I came across a site that was questioning the need for OO (Object Oriented) code in a language like ColdFusion. The author suggested that PP (Procedural Programming) was often faster as it involved much less overhead, and asked the question if it was truly necessary to strictly separate business logic from display code. I could see points in this persons argument up to this point. Not separate logic from display, was he mad? Still, to a developer who has not worked on complex applications, and has stuck strictly to commercial sites, I can see where the computing overhead and design complexity required of creating usable software would seem absurd. I can even see where EPAI (Every Page is an Island) can be of benefit in commercial sites with only several dynamic pages.

Having maintained large applications developed both with a framework and using elements of OO, as well as maintaining large applications built with no framework and EPAI, I can definately say that the applications developed with the framework and elements of OO are much easier to take care of. The primary reason is that there is a higher level of encapsulation per object, so that each individual object does only one task, and that task it could perform independent of any other objects. This way it is very easy to troubleshoot that one piece. As you continue through troubleshooting each piece you are most assured to find the issue. With EPAI, troubleshooting becomes difficult because each page has display logic mixed in, and can be performing several tasks, especially if it is sumitted to itself in forms. Even with appropriate variable scoping, it is still hard to determine what is setting what where.

I would suggest that the person who suggested that there was no benefit to separating business logic from presentation logic read Design Patterns by the Gang of Four, Gamma, Helm, Johnson, Vlissides. After reading a brief excerpt from the preface of the book I knew that it could help me solve some of my design problems. The issues in the book are real-world issues and as such the solutions make sense. After reading this book, the extra system overhead and complexity should seem worth it in many cases. However, this does not mean that it applies in all cases. Invariably there will be exceptions, for example where performance is the highest priority for a given operation. In this case you may wish to bypass the framework you have developed or are using for this operation, if the overhead it incurs is significant. This is just one example of many where design patterns and maybe even OO may not be the best solution to a problem. Remember, that is what programmers are doing, solving problems. Design patterns are just to give us more tools to do so.