业务层的jsp

Question

为什么我们不应该将JSP用于业务层？

是表现吗？ 还是仅仅是一个好习惯？ 当然可以重用是其中一个原因。除此之外，为什么我们应该将jsp用于业务层呢？

Answer 1

通常的原因是关注点分离。您应该轻松修改演示文稿而不影响业务层。

Answer 2

可重用性和可维护性是一些巨大的问题。

考虑下面的情况;

1. 假设你想创建一个iPhone 版本的应用程序，你必须 到端口的所有业务逻辑 的iPhone，现在让我们拥有了 申请一个Eclipse RCP前端和基于闪存;然后与基于Python的系统集成。

2. 由于业务逻辑和 呈现在同一个文件， 创意Web开发有 学习一些Java，如果他要 不 打破了应用程序创建的最佳接口。

Answer 3

如果您制作的应用程序超过5页，混合逻辑和演示文稿可能会让您的生活更加艰难。但是，这是我的一个不受欢迎的观点 - 对于小型应用程序（甚至是中型应用程序），只需一个“知道他的代码”的开发人员，就可以将JSP用于buisness逻辑。它可能是jsps放在/action/文件夹中，稍后重定向到演示文件夹，或者它可能与请求来自的jsps相同。我举了一个例子 - 在开发实践之初，我基于网络策略游戏几乎完全基于自我发布jsps。那是5年前。几个星期前我看了一下我的代码库，我可以理解所有的东西。所以，如果你刚刚开始，而且你不想从一个能让你的学习曲线更陡峭的大框架开始，并且你不希望你的项目变得非常大或者变成商业化的（旁注：我的商业变得商业化然后随意使用jsps作为业务逻辑，但需要注意的是在常见情况下这不是一个好习惯。

Answer 4

几个原因：

1. 重用性：你不能再使用小脚本。
2. 可替换性：不能使脚本抽象化。
3. OO能力：你不能使用继承/组合。
4. 可调试性：如果scriptlet中途抛出一个异常，你得到的只是一个空白页面。
5. 可测试性：scriptlet不是单元可测试的。
6. 可维护性：每个saldo需要更多的时间来维护混合/混乱的代码逻辑。

还有更多，但它归结为脚本是坏习惯。

您可以在表示层JSTL和EL做相当多的工作。如果您认为这两种方法都不可行，并且您不得不抓取scriptlet，那么代码逻辑最终属于一个真正的Java类。您可以使用一个Servlet类来控制/预处理/后处理请求，您可以使用Filter类来过滤请求，您可以使用DAO类来完成数据库交互，可以使用Javabean类来存储/传输/访问数据，您可以使用Domain类作为业务逻辑，您可以使用Utility类作为静态工具。