业务层的jsp

Question

为什么我们不应该在业务层使用JSP？

是表演吗？还是只是一个好习惯？当然，可重复使用性是原因之一，除此之外，还有什么杀手级的理由为什么我们应该将jsp用于业务层？

Answer 1

几个原因：可重用性：您无法重用scriptlet。可替换性：您不能使scriptlet抽象。面向对象的能力：您不能利用继承/组合。可调试性：如果scriptlet在中途抛出异常，您得到的只是空白页。可测试性：脚本无法进行单元测试。可维护性：每一次交易需要更多时间来维护混杂/混乱的代码逻辑。还有更多，但是归根结底，scriptlet是一种不好的做法。您可以使用JSTL和EL在表示层上做很多事情。如果您发现它们中的任何一个都是不可能的，并且您被迫获取scriptlet，那么代码逻辑最终属于真正的 Java类。您可以使用一个Servlet类来控制/预处理/后处理请求，可以使用一个Filter类来过滤请求，可以使用一个DAO类来进行数据库交互，可以使用一个Javabean类来存储/传输/访问数据，可以使用一个Domain用于业务逻辑的Utility类，可以将类用于静态工具。

Answer 2

通常的原因是关注点分离。您应该使修改演示文稿变得容易，而又不影响业务层。

Answer 3

如果您要编写的应用程序超过5页，则混合使用逻辑和表示可能会使您的生活更加艰难。但是，这是我的一个不受欢迎的观点-对于小型应用程序（甚至中型应用程序），只有一个“知道他的代码”的开发人员，可以将JSP用于业务逻辑。可能是将jsps放在/action/文件夹，以后再重定向到演示文稿文件夹，也可以是请求来自的相同jsps。我有一个例子-在开发实践的开始，我制作了一个几乎完全基于自发布jsps的基于Web的策略游戏。那是五年前。几周前，我看了一下我的代码库，我了解了所有内容。因此，如果您才刚刚开始，并且不想以一个大型框架作为起点，而这个大型框架会使您的学习曲线更加陡峭，并且您不希望自己的项目太大或变得商业化（注：我的商业化了）一方面，您可以随意将jsps用于业务逻辑，但是请注意，在通常情况下，这不是一个好习惯。