JSP脚本与MVC在性能方面的比较

Question

我参加了一次面试，该公司的首席技术官告诉我他们有一个系统已经运行了五年，但仍然不喜欢纯粹使用MVC框架，原因是性能问题。我知道大多数MVC框架使用反射来调用方法（这本质上是慢的），但是许多MVC框架（例如Struts）会缓存其调用的方法，这样就不必一直“查找”要调用的方法。

目前，他们坚持使用scriptlets（而且不使用JSPTags）。我想知道，在性能方面，纯scriplets是否比MVC更高效？他们更喜欢无状态会话而非有状态会话，以避免会话迁移、会话跟踪等问题。

如果首席技术官所说的是真的，那么为什么MVC仍然更受欢迎呢？（我知道MVC的作用，但与性能相关）。

- Buhake Sindi

---

听起来不是我想要工作的公司。写商业级Java Web应用程序而*不使用任何形式的MVC框架是愚蠢的。此外，脚本片段会导致XSS攻击，应该被禁止，而不是被鼓励。 - Qwerky

通过！我可能提前离开了面试。 - Chris Wagner

Answer 1

反对观点：

• 自好几年前起，反射已经不再那么慢了。
• 硬件性能在过去几年里疯狂提高。
• MVC最终导致更快的开发。少浪费时间=节省更多的$$$。

我会放弃这份工作。

- BalusC

Answer 2

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

反对脚本片段的论点

• 我不喜欢脚本片段，因为它们极其难以维护。它们也容易被滥用。最大的问题是它们混淆了视图逻辑和业务逻辑，或者至少使得这样做变得非常容易和诱人。

• 你可以明智地分离出你的关注点并使用拉取数据的服务（从而促进重用）。但更多时候，我看到开发人员像PHP代码一样编写JSP（即将代码与标记混合在一起）。

我并不是说你不能用JSP编写好的代码。只是这更难（我觉得MVC有更多的保障），而且（我感觉）JSP更容易被滥用。

MCV的论点

• 回答你的第二个问题，MVC是首选的，因为它天生就促进了关注点分离，并且不允许来自不同区域的逻辑混杂在一起。

• 视图层仅关注于呈现视图。您从控制器获取元数据，并使用视图显示数据。您在这里不关心业务逻辑（也不应该关心）。

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

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

• 反射并不那么慢。此外，现代计算机速度非常快，内存很大。性能并不是太大的问题。

• MVC模式促进了不同关注点之间的清晰分离，使开发人员能够编写干净、健壮和易于维护的代码。

- Vivin Paliath

---

考虑到我已经说过“我知道MVC的存在意义”，你实际上去做了那件事...但是分享知识总是好的。 - Buhake Sindi

@The Elite Gentleman 哎呀，抱歉我有点激动了 :) 我是想说明为什么MVC比脚本片段更好。我以为这就是你想要的 :) - Vivin Paliath

我只是想进行性能比较。我强烈支持MVC。我重新表述了我的问题标题，以使其更加清晰。不要编辑你的答案，这将有助于旁边的人 ;) - Buhake Sindi

@The Elite Gentleman 明白了。我在我的论点中提到了这一点。但是我认为，整体来看，解释什么是MVC也有助于加强性能论据（它指出了使用脚本标记的缺点）。 - Vivin Paliath

Answer 3

MVC相对于脚本片段的优势在其他答案中已经完美地描述了，但是有一点被忽略了。

反射相对于直接方法调用引入了一些开销。当您频繁使用反射调用简单方法时，这很重要。但是，单个反射调用引入的开销与典型Web应用程序中的整体请求处理时间相比并不重要。因此，在这种特定情况下出于性能原因决定不使用反射听起来很奇怪。

- axtavt