jsp for business layer

Question

Why shouldn't we use JSP for business layer?

Is it performance? Or is it just a good practise? Ofcourse reusablity is one reason.Other than that is there any killer reason why we should use jsp for business layer?

Answer 1

The usual reason is separation of concerns. You should make it easy to modify the presentation without affecting the business layer.

Answer 2

Reusability and Maintainability are some of the huge issue.

Consider the situation below;

1. Imagine you want to create an iPhone version of the application, you have to port all the business logic to the iPhone, now lets have an Eclipse RCP frontend for the application and a Flash based; then integrate with a Python based system.

2. Because the business logic and the presentation are in the same file, the creative Web Developer has to learn some Java if he is going to create the best interface without breaking the application.

Answer 3

If you are making an application that is more than 5 pages, mixing logic and presentation could make your life harder. But here is an unpopular opinion of mine - for small applications (or even medium-ones), with a single developer that 'knows his code', it is OK to use JSPs for buisness logic. It could be jsps placed in an /action/ folder, that later redirect to the presentation ones, or it could be the same jsps where the request comes from. I have an example for that - in the beginning of my development practice I made a web-based strategy game based almost entirely on self-posting jsps. That was 5 years ago. A few weeks ago I took a look at my codebase, and I could understand everything. So if you are just beginning, and you don't want to start with a big framework that will make your learning curve even steeper, and you don't expect your project to be very large or to become commercial (sidenote: mine became commercial at one point), then feel free to use jsps for business logic, but be adviced that this is not a good practice in the common case.

Answer 4

Several reasons:

1. Reusability: you can't reuse scriptlets.
2. Replaceability: you can't make scriptlets abstract.
3. OO-ability: you can't make use of inheritance/composition.
4. Debuggability: if scriptlet throws an exception halfway, all you get is a blank page.
5. Testability: scriptlets are not unit-testable.
6. Maintainability: per saldo more time is needed to maintain mingled/cluttered code logic.

There are more, but it boils down that scriptlets are a bad practice.

You can do fairly a lot at the presentation layer with JSTL and EL. If you comes to a point that it is not possible with either of them and you're forced to grab scriptlets, then the code logic ultimately belongs in a real Java class. You can use a Servlet class to control/preprocess/postprocess requests, you can use a Filter class to filter requests, you can use a DAO class to do the database interaction, you can use a Javabean class to store/transfer/access data, you can use a Domain class for business logic, you can use an Utility class for static tools.