我來自一次訪談，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