JSP Scriptlet 与 MVC 在性能方面的比较

Question

我面试回来，CTO（首席技术官）告诉我，有一个系统（已经运行了5年多了），他们仍然不喜欢纯粹为了性能而使用MVC。我知道大多数 MVC 使用反射来调用方法（这本质上很慢），但是许多 MVC（我知道 Struts 这样做，我读过代码）缓存它调用的方法，因此我不必“找到”方法一直调用。

目前，他们坚持使用 scriptlet（并且不使用 JSPTag）。我想知道，纯粹的 scriplet 是否比 MVC 有巨大的性能？他们更喜欢无状态会话而不是有状态会话，以避免会话迁移、会话跟踪等。

如果 CTO 所说的是真的，为什么 MVC 仍然是首选（我知道为什么 MVC 存在，但是是关于性能的）。

Answer 1

反对论点：

• 反射不是 那 好几年以来，速度已经变慢了。
• 过去几年，硬件性能得到了疯狂的提高。
• MVC 最终导致更快的开发。浪费的时间越少 = 节省的钱就越多。

我会通过这份工作。

Answer 2

CTO 的逻辑相当奇怪；我认为他不知道自己在说什么（提示：通过这份工作！）如果他这么担心效率，为什么不用汇编语言重写整个 webapp？

反对 scriptlet 的争论

• 我不喜欢小脚本，因为它们非常难以维护。他们也容易受到虐待。最重要的是，它们将视图逻辑与业务逻辑混合在一起，或者至少，使得做同样的事情变得非常容易和诱人。

• 你 可以 明智地分离出您的担忧并使用提取数据的服务（从而促进重复使用）。但我经常看到开发人员像 PHP 代码一样编写 JSP（即与标记混合的代码）。

我不是说你 不能 使用 JSP 编写良好的代码。只是它更难（我觉得 MVC 有更多的保护措施）并且（我觉得）JSP 更容易被滥用。

MCV 的论点

• 为了回答你的第二个问题，MVC 是首选，因为从本质上讲，它促进关注点分离，并且不允许来自不同区域的逻辑渗透到其他区域。

• 视图层只关心渲染视图。您从控制器获取元数据，并使用视图显示数据。您不关心这里的业务逻辑（而且您不应该关心）。

• 控制器就像交通警察一样，将您的请求重定向到正确的目的地。控制器通常最终调用执行所有业务逻辑的服务。

• 该模型负责应用程序域的数据和行为。该模型将响应有关其状态的请求（因此这是您发送到视图的元数据），并且还将响应告诉其更改状态的指令（来自控制器）。

• 反思确实没那么慢。此外，现在的计算机速度非常快，并且具有大量内存。性能并不是那么令人担忧。

• MVC 模式促进了不同关注点之间的清晰分离，使开发人员可以轻松编写干净、健壮且可维护的代码。

Answer 3

过小脚本MVC的优点是完全在其他的答案说明，但一个点被遗漏。

反射引入了一些开销相比直接方法调用。当您使用反射来经常致电简单的方法，它很重要。但是开销由一个反射调用介绍无所谓相比，一个典型的Web应用程序的总体要求处理时间。因此决定不在这种特殊情况下出于性能原因使用反射声音奇怪。