我来自一次访谈，CTO（首席技术官）告诉我，有一个系统（已运行超过5年），他们仍然不愿意使用MVC完全依赖于性能。我知道大多数MVC使用反射来调用方法（实际上它很慢），但是很多MVC（我知道Struts做到了，我读了代码）缓存了它调用的方法，所以我不必“找到”方法始终调用。JSP Scriptlet与MVC在性能方面的比较
现在，他们坚持scriptlets（并且他们不使用JSPTags）。我想知道，是否有比MVC纯粹的脚本更大的性能？他们更喜欢无状态和有状态的会话，以避免会话迁移，会话跟踪等。
如果CTO说的是真的，为什么MVC仍然是首选（我知道为什么MVC在那里，但关于性能）。
魂斗罗参数：
我会通过这份工作。
我有完全一样的想法.... :)，我正在考虑通过这项工作。 – 2010-11-18 15:55:16
这是来自CTO的相当奇怪的逻辑;我不认为他知道他在说什么（提示：通过工作！）如果他对效率如此担心，为什么不用汇编语言重写整个webapp呢？
理由反对小脚本
我不喜欢小脚本，因为它们非常难以维持。他们也容易被滥用。最大的问题在于，它们将视图逻辑与业务逻辑混淆在一起，或者至少让它变得非常容易和诱人。
你可能明智地分出你的顾虑和使用拉取数据（从而促进重复使用）的服务。但更多的时候，我见过开发人员编写像PHP代码一样的JSP（即使用标记混合代码）。
我不是说你无法写JSP中好的代码。这只是它更难（我觉得MVC有更多的保护措施），（我觉得）JSP更容易被滥用。
参数的MCV
要回答你的第二个问题，MVC是因为自然首选，它促进了关注点分离，不允许从不同区域的逻辑渗到其他领域。
视图层只关心渲染视图。您从控制器获取元数据，并使用视图显示数据。你不关心这里的商业逻辑（你不应该）。
控制器就像一个交通警察，将您的请求重定向到正确的目的地。控制器通常最终会调用执行所有业务逻辑的服务。
该模型负责应用程序域的数据和行为。该模型将响应有关其状态的请求（因此这是您发送到视图的元数据），并且还将响应指示它改变状态的指令（来自控制器）。
反映真的不是那么慢。另外，现在电脑速度非常快，而且内存很大。表现并不是那么重要。
MVC模式促进了不同关注点之间的清晰分离，使开发人员可以轻松编写干净，健壮且可维护的代码。
考虑到我已经说过'我知道为什么MVC就在那里'，你实际上就是这么做的......但尽管如此，分享知识也是很好的...... – 2010-11-18 15:57:43
@The精英绅士哎呀，对不起，我被带走了:)我试图说明为什么MVC比scriptlet更好。我以为这就是你想要的:) – 2010-11-18 15:58:39
我只想要进行性能比较。我强烈要求MVC。我重新提出了我的问题标题，以清楚地说明问题。不要编辑你的答案，它会帮助隔壁的家伙;） – 2010-11-18 16:00:43
MVC优于Scriptlet的优点在其他答案中有很好的描述，但有一点是错过的。
与直接方法调用相比，反射引入了一些开销。当你使用反射来经常调用简单的方法时，这很重要。但是与典型Web应用程序中的总体请求处理时间相比，通过单个反射调用引入的开销并不重要。因此，在这种特殊情况下决定不使用反射来改善性能听起来很奇怪。
听起来不像我想工作的公司。编写商业化的Java Web应用程序*而不使用某种形式的基于MVC的框架是愚蠢的。另外脚本邀请XSS，应该禁止，不鼓励。 – Qwerky 2010-11-18 16:29:17
通过！我可能早就离开了采访。 – 2010-11-18 18:34:16