JSP Scriptlet 与 MVC 在性能方面的比较
我面试回来，CTO（首席技术官）告诉我，有一个系统（已经运行了5年多了），他们仍然不愿意纯粹为了性能而使用MVC。我知道大多数 MVC 使用反射来调用方法（这本质上很慢），但是许多 MVC（我知道 Struts 这样做，我读过代码）缓存了它调用的方法，所以我不必“找到”方法一直调用。
目前，他们坚持使用 scriptlet（并且不使用 JSPTag）。我想知道，纯粹的 scriplet 是否比 MVC 有巨大的性能？他们更喜欢无状态会话而不是有状态会话，以避免会话迁移、会话跟踪等。
如果 CTO 所说的是真的，为什么 MVC 仍然是首选（我知道为什么 MVC 存在，但与性能有关）。
I came from an interview and the CTO (Chief Technology Officer) told me that there have a system (which has been running for over 5 years) and they still prefer not to use MVC purely on performance. I know most MVC uses reflection to invoke methods (which is, in essence slow) but many MVC (I know Struts does it, I read the code) cache the methods it invokes so I doesn't have to "find" the method to invoke all the time.
For now, they stick to scriptlets (and they don't use JSPTags). I wonder, is there a huge performance going purely scriplets than MVC? They prefer stateless vs stateful sessions to avoid session migration, session tracking, etc.
If what the CTO says is true, why is MVC still preferred (I know why MVC is there, but with regards to performance).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
反驳观点：
我会通过这份工作。
Contra arguments:
I'd pass the job.
CTO 的逻辑相当奇怪；我认为他不知道自己在说什么（提示：通过这份工作！）如果他如此担心效率，为什么不用汇编语言重写整个 webapp？
反对 scriptlet 的争论
我不喜欢 scriptlet，因为它们非常难以维护。他们也容易受到虐待。最重要的是，它们将视图逻辑与业务逻辑混合在一起，或者至少，使做同样的事情变得非常容易和诱人。
您可以明智地分离出您的担忧并使用提取数据的服务（从而促进重复使用）。但我经常看到开发人员编写像 PHP 代码一样的 JSP（即与标记混合的代码）。
我并不是说您不能用JSP 编写出好的代码。只是它更难（我觉得 MVC 有更多的保护措施）并且（我觉得）JSP 更容易被滥用。
MCV 的论据
要回答你的第二个问题，MVC 是首选，因为从本质上讲，它促进关注点分离，并且不允许来自不同区域的逻辑渗透到其他区域。
视图层只关心渲染视图。您从控制器获取元数据，并使用视图显示数据。您不关心这里的业务逻辑（也不应该关心）。
控制器就像交通警察一样，将您的请求重定向到正确的目的地。控制器通常最终会调用执行所有业务逻辑的服务。
模型负责应用程序域的数据和行为。该模型将响应有关其状态的请求（因此这是您发送到视图的元数据），并且还将响应告诉其更改状态的指令（来自控制器）。
反射确实没那么慢。此外，现在的计算机速度非常快，并且具有大量内存。性能并不是那么重要。
MVC 模式促进不同关注点之间的清晰分离，使开发人员可以轻松编写干净、健壮且可维护的代码。
That's rather strange logic from the CTO; I don't think he knows what he's talking about (hint: pass the job!) If he's so worried about efficiency, why not rewrite the whole webapp in assembly language?
Arguments against scriptlets
I don't like scriptlets because they are notoriously difficult to maintain. They are also prone to abuse. The biggest thing is also that they mix up view-logic with business-logic, or at the very least, make it extremely easy and tempting to do the same.
You could judiciously separate out your concerns and use services that pull in data (and thus promote re-use). But more often than not, I've seen developers write JSPs like PHP code (i.e., code mixed in with markup).
I am not saying that you can't write good code with JSPs. It's just that it's harder (I feel MVC has more safeguards) and also (I feel) JSP's are more prone to abuse.
Arguments for MCV
To answer your second question, MVC is preferred because by nature, it promotes separation of concerns and doesn't allow logic from the separate areas to bleed into the other areas.
The view layer is solely concerned with rendering the view. You get metadata from your controller, and you display the data using the view. You are not concerned about the business logic here (and you shouldn't be).
The controller acts like a traffic-cop, redirecting your requests to their proper destinations. Controllers usually end up calling services that perform all the business logic.
The model is in charge of the data and behavior of the application domain. The model will respond to requests about its state (so this is the metadata that you're sending to the view) and will also respond to instructions that tell it to change state (from the controller).
Reflection really isn't that slow. Also, computers are pretty fast these days and come with a lot of memory. Performance isn't that much of a concern.
The MVC pattern promotes a clean separation between the different concerns that makes it easy for the developer to write clean, robust, and maintainable code.
MVC 相对于 scriptlet 的优点在其他答案中得到了完美的描述，但遗漏了一点。
与直接方法调用相比，反射引入了一些开销。当您使用反射频繁调用简单方法时，这一点很重要。但与典型 Web 应用程序中的总体请求处理时间相比，单个反射调用带来的开销并不重要。因此，在这种特殊情况下，出于性能原因而不使用反射的决定听起来很奇怪。
Advantages of MVC over scriptlets is perfectly described in other answers, but one point is missed.
Reflection introduces some an overhead compared to direct method calls. It matters when you use reflection to call simple methods frequently. But overhead introduced by a single reflective call doesn't matter compared to the overall request processing time in a typical web application. Therefore decision not to use reflection for performance reasons in this particular case sounds strange.