Response to Web Application: To Couple or Not to Couple?

I just read this thread on The Server Side and it makes me nervous that people still ask this kind of question. The thread starts off by asking “An usually annoying question when designing an action-based web application is: “Should I place everything in my action or should I separate the web logic from the business logic?” and the alarm bells in my head are going off already.

Business logic always belongs in its own layer. Why? Business logic is the thing that makes your application what it is. It doesn’t matter how it’s dressed up - web app, desktop app, web service - the business logic accomplishes the task the user wants to perform. Business logic is your application. Because of its importance business logic should be placed in a sacred place where it will not be disturbed by presentation logic or infrastructure underpinnings - the business tier. Separating the business concerns from all other concerns buys a lot of benefits for the development team.

What if aggregate data must be displayed in multiple locations? For example, shopping cart data could be displayed on a checkout screen and also as a side bar while the user is still shopping. In an action-based framework this code would be duplicated in two different actions. It would be present in the action that generated checkout screen and again in the action that assembled the shopping view screen. Rather than duplicate the code why not make a method call into the business layer that did the same thing? The end result is the same except it separates the concerns of web and business logic.

Refactoring this code into a business tier method helps make our application more loosely coupled. Loose coupling is important for business logic because it allows for easier reuse, testability and maintanence. If the business logic is located in the action then creating a web service around it is going to be more difficult. The business logic will have to be decouple from the web action and pulled into a layer where both the web action and web service can use it. A good example of this would be a web page that displays new items available to a customer. A web page is ok but the customer would have to keep checking back for updates. An easier way to publish this information would be to make it available as an RSS feed the customer can subscribe to. Duplicating the logic to get the new items isn’t particularly difficult, but why make maintenance more difficult than it has to be? The application should be refactored to have a business layer that is responsible for getting the data which can be called by two different locations in the presentation layer (the web tier and the RSS feed creator). Testing the business logic (you’re testing, right?) and bug fixing only have to be done in one location thanks to this refactoring too.

Another quote from the thread is, “The other side of the story is that to have two separate classes, one dealing with the http/web layer (ex: UserAction) and one dealing with the business logic layer (ex: UserService) is bureaucratic.” This statement shows a lack of understanding of functional decomposition. Each module should be responsible for one and only one thing. If the web layer is for dealing with actions then actions should only be dealt with in the web layer. If the web layer is for dealing with actions then business logic should not be dealt with at the web layer. Business logic belongs where it can remain undisturbed by other concerns. Tight coupling of these concerns makes testing more difficult because it requires testing everything it once rather than testing in isolation. Because your application is only as good as the business logic the business layer should have a test suite that can be run without depending on action or presentation logic.

There are plenty of other reasons you should keep business and web logic separate. This is in no way an exhaustive list, but it’s certainly something to think about. If you’re building any professional application then business logic should always be in its own layer. Not only will your boss/team/successor thank you for it, it’s good software development and you’ll thank yourself for it too.