我从面试中过来，CTO（首席技术官）告诉我有一个系统（已经运行了 5 年多），他们仍然不喜欢纯粹出于性能考虑使用 MVC。我知道大多数 MVC 使用反射来调用方法（这实际上很慢）但是许多 MVC（我知道 Struts 会这样做，我阅读了代码）缓存它调用的方法，所以我不必“找到”方法来一直调用。
目前，他们坚持使用 scriptlet（并且他们不使用 JSPTags）。我想知道，纯粹的 scriplets 是否有比 MVC 更好的性能？他们更喜欢无状态会话而不是有状态会话，以避免会话迁移、会话跟踪等。
如果 CTO 说的是真的，为什么仍然首选 MVC（我知道 MVC 存在的原因，但就性能而言）。
反论点：
我会通过工作。
这是来自 CTO 的相当奇怪的逻辑。我不认为他知道他在说什么（提示：通过工作！）如果他如此担心效率，为什么不用汇编语言重写整个 webapp？
反对 scriptlet 的论据
我不喜欢scriptlet，因为它们是出了名的难以维护。他们也容易受到虐待。最重要的是，他们将视图逻辑与业务逻辑混为一谈，或者至少，使其变得非常容易和诱人。
您可以明智地分离出您的关注点并使用提取数据的服务（从而促进重用）。但我经常看到开发人员编写 JSP 之类的 PHP 代码（即，与标记混合的代码）。
我并不是说你不能用 JSP 编写好的代码。只是它更难（我觉得 MVC 有更多的保护措施）而且（我觉得）JSP 更容易被滥用。
MCV 的参数
要回答您的第二个问题，首选 MVC，因为从本质上讲，它促进关注点分离，并且不允许来自单独区域的逻辑渗入其他区域。
视图层只关心渲染视图。您从控制器获取元数据，并使用视图显示数据。你不关心这里的业务逻辑（你不应该关心）。
控制器就像交通警察一样，将您的请求重定向到正确的目的地。控制器通常最终调用执行所有业务逻辑的服务。
该模型负责应用程序域的数据和行为。模型将响应有关其状态的请求（因此这是您发送到视图的元数据），并且还将响应告诉它更改状态的指令（来自控制器）。
反射真的没那么慢。此外，如今的计算机速度非常快，并且具有大量内存。性能并不是什么大问题。
MVC 模式促进了不同关注点之间的清晰分离，使开发人员可以轻松编写干净、健壮和可维护的代码。
MVC 相对于 scriptlet 的优势在其他答案中得到了完美的描述，但遗漏了一点。
与直接方法调用相比，反射引入了一些开销。当您使用反射频繁调用简单方法时，这很重要。但是与典型 Web 应用程序中的整体请求处理时间相比，单个反射调用引入的开销并不重要。因此，在这种特殊情况下，出于性能原因决定不使用反射听起来很奇怪。