开发者

jsp for business layer [closed]

开发者 https://www.devze.com 2022-12-12 21:22 出处:网络
开发者_如何学运维 As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references,or expertise, but this question will likely
开发者_如何学运维 As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 9 years ago.

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?


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.


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


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.


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消