我希望有人在这个问题中解释一下BlausC的惊人答案.
他说小脚本有一些缺点,它们是:
可重用性:您无法重用scriptlet.我的问题:我怎样才能重用JSTL代码？
可替换性:您不能使scriptlet抽象化.抽象是什么意思,JST如何变得抽象？
OO:你不能利用继承/组合.我如何在JSTL中使用OO范例？
调试:如果一个scriptlet中途抛出异常,你得到的只是一个空白页面.
可测试性:scriptlet不能进行单元测试.这是什么意思,JSTL如何进行单元测试？
可维护性:每个saldo,需要更多的时间来维护混杂/混乱/重复的代码逻辑.这是什么意思？
最后一件事是他引用甲骨文的建议:
JSP scriptlet不应该用于编写业务逻辑.
在MVC模式中,我仅在表示层中使用scriptlet.他在这里是什么意思？
Bal*_*usC 16
你似乎集中在只有小脚本中使用的演示文稿和流量控制部件if,for并switch 声明和out.print()事情.您似乎将Scriptlet 1:1与JSTL进行比较.这是错的.我不是只谈论流控制部分(实际上是由JSTL取代),而是关于在JSP文件中编写原始Java代码.即收集请求参数,验证和转换值,与数据库和其他Java类/方法交互等等.您通常(间接)在Servlet或Filter中执行的所有操作.
duf*_*ymo 14
你应该不是在JSP中的scriptlet代码.我推荐100%JSTL和零scriplet代码.
JSP应该是纯粹的表示.这是使用JSTL编写JSP的隐藏好处,因为它们可以在其他地方获取所有动态数据.让服务层具有业务逻辑并确定JSP需要哪些数据.
这也回答了你的单元测试问题.您不应该单元测试JSP; 那些将是类似Selenium的UI测试.如果逻辑位于服务层中,那么测试它的方式就很明显了.
不应继承JSP.你当然可以使用类似SiteMesh的东西将它们组合在一起,但继承在你的JSP中没有任何作用.一旦他们从Servlet继承,链就应该结束了.
此外,这是一个错误的选择.两者都不应该要求重用,继承或单元测试.但这并不意味着没有一个明显的赢家:它是JSTL.没有人应该在JSP中使用scriptlet,除了非常罕见的单行程序.Scriptlets正在乞求麻烦.
这些天我更喜欢Velocity作为Java的Web UI模板解决方案,而不仅仅是JSP.只是我的观点.
| 归档时间： |
|
| 查看次数： |
27911 次 |
| 最近记录： |