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

Question

我来自一次采访，CTO（首席技术官）告诉我，有一个系统（已运行超过5年），他们仍然不愿仅仅在性能上使用MVC。我知道大多数MVC使用反射来调用方法（实际上很慢）但很多MVC（我知道Struts会这样做，我读代码）缓存它调用的方法所以我不必“找到”方法来一直调用。

目前，他们坚持使用scriptlet（并且他们不使用JSPTags）。我想知道，是否有一个巨大的表现纯粹是文字比MVC？他们更喜欢无状态会话和有状态会话，以避免会话迁移，会话跟踪等。

如果CTO说的是真的，为什么MVC仍然是首选（我知道为什么MVC在那里，但在性能方面）。

Answer 1

反对论点：

• 自从好几年以来，反思不再是 慢了。
• 过去几年，硬件性能急剧增加。
• MVC最终导致更快的发展。减少浪费时间=更多$$$节省。

我通过了这份工作。

Answer 2

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

针对scriptlet的参数

• 我不喜欢scriptlet，因为它们很难维护。他们也容易被滥用。最重要的是，它们将视图逻辑与业务逻辑混合在一起，或者至少使它变得非常容易和诱人。

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

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

MCV的参数

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

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

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

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

• 反思真的不是那么慢。此外，如今计算机速度非常快，而且内存很多。表现并不是一个值得关注的问题。

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

Answer 3

MVC优于scriptlet的优点在其他答案中有完美描述，但遗漏了一点。

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