大型網站的MVC風格適合哪種粒度的控制器？

Question

我們（我的團隊和我）有一個大型的網絡項目，可以處理很多用戶（至少有15,000個用戶！）。在精化階段，我們決定使用MVC風格進行編碼。我們面臨權衡（在這個項目中，所有的行爲都應該由經過認證的用戶來執行）。

設計的一種方法可能是：控制器獲取請求，並根據它創建（從DB加載）負責對象的請求，然後將該對象的引用保存到控制器，最後添加控制器到用戶的會話。這種風格需要控制器成爲具有高頻率的用戶可能行爲中的多個行爲的粗粒度類。

設計的另一種方式可以是：控制器得到的請求，然後創建一個請求負責對象，但該控制器是無狀態的，有根據，例如網站的一個頁面的特定行爲。通過這種方式，我們應該爲每個頁面創建一個控制器，並且如果它需要某些頁面中常見的信息，我們必須從DB或緩存中加載它們。

• 在第一個樣式，控制器應該是因爲減少創建和垃圾回收的粗顆粒狀物體，因此它創建用戶通過認證後，並不會被垃圾，直到會話過期一次。會話中存在的對象的生命週期是一直到會話過期，所以我認爲這可能會導致內存不足！
• 在第二風格的用戶到其他頁面的每一個轉型控制器應創建並從數據庫中提取信息，可能會導致性能問題！

我的要求：我想比較它們與兩個方面，內存使用情況和性能！如果有任何建議，我會很樂意提到它！

舉個簡單的例子，請參見下面的圖片：

http://v1.iimmgg.com/images/is7gr/fb0f6b763eea5294815dcb2d50a12f56.png

Answer 1

我的經驗法則是按照REST principles

每個企業實體是一種資源。資源應該有控制器。

值對象，像電子郵件，資金等均不資源。

在少數情況下，當簡單了權重的複雜額外的控制器將增加和實體直接相關的控制器應合併。

Answer 2

實際上將許多控制器網站將不會讓但從DB accesss點差，因爲對象保持整個會議期間。在許多控制器中分割網站並不意味着你在分割會話。

Answer 3

大部分的時間你的數據訪問層決定了系統的在MVC應用程序控制器的尺寸幾乎沒有影響性能。從設計角度來看，我建議你在一個控制器中保持邏輯相關的動作，這樣你可以有很多小控制器。爲了性能的角度來看，你應該關注你的數據庫訪問並找到它所屬的優化。