我希望有人解释BlausC在这个问题上的惊人答案中的一些观点。
他说，scriptlet有一些缺点，它们是：
可重用性：您无法重用脚本。我的问题：如何重用JSTL代码？
可替换性：你不能使脚本变得抽象。抽象是什么意思，JST如何成为抽象？
OO：你不能利用继承/组合。如何在 JSTL 中使用 OO 范例？
调试：如果一个脚本在中途抛出异常，你得到的只是一个空白页。
可测试性：脚本不能进行单元测试。这是什么意思，如何对JSTL进行单元测试？
可维护性：根据saldo，需要更多的时间来维护混合/混乱/重复的代码逻辑。这是什么意思？
最后一件事是他引用甲骨文建议的内容：
JSP 脚本不应用于编写业务逻辑。
在 MVC 模式中，我只在表示层中使用脚本。他在这里是什么意思？
您似乎只专注于脚本的表示和流控制部分，就像使用 、和语句和事物一样。你似乎将脚本 1：1 与 JSTL 进行了比较。这是错误的。我说的不仅仅是流控制部分（它确实要被JSTL取代），而是一般地在JSP文件中编写原始Java代码。即收集请求参数，验证和转换值，与数据库和其他Java类/方法进行交互等。您通常（间接）在Servlet或过滤器中执行的所有操作。ifforswitchout.print()
JSP 中不应有脚本代码。我建议使用100%的JSTL和零scriiplet代码。
JSP 应纯粹表示。这就是仅使用 JSTL 编写 JSP 的隐藏优势，因为它们在其他地方获取所有动态数据。让服务层具有业务逻辑，并确定 JSP 需要哪些数据。
这也回答了您的单元测试问题。您不必对 JSP 进行单元测试;这些将是类似硒的UI测试。如果逻辑位于服务层中，则测试它的方式显而易见。
不应继承 JSP。您当然可以使用像SiteMesh之类的东西将它们组合在一起，但是继承在您的JSP中没有部分。一旦它们从Servlet继承，链就应该结束了。
此外，这是一个错误的替代方案。两者都不需要重用、继承或单元测试。但这并不意味着没有明确的赢家：它是JSTL。没有人应该在 JSP 中使用 scriptlet，除了非常罕见的单行代码。脚本小包在乞求麻烦。
如今，我更喜欢Velocity作为我的Java Web UI模板解决方案，而不是JSP。只是我的意见。
