基於MVC的系統通用文件/文件夾結構

Question

我想弄清楚基於MVC設計的系統的類，方法，文件和文件夾的正確佈局。

假設我們有一個頁面。 頁面是一個帶標題，文本和子菜單的簡單頁面。它還可以包括一個畫廊（這將成爲數據庫和代碼中的獨立對象）。

1. 我想有一個PageDAO類，將有所有數據庫相關的功能（這將延長主機DAO類，這將持有通用數據庫的功能選擇，保存，刪除等）

2. 我會單獨的頁面類將爲此對象定義變量和非數據庫相關功能

3. 我將擁有MVC本身，其中PageModel將構建頁面DAO類和頁面類和構建內容，然後將進行在控制器中準備一個視圖

4. 畫廊將被定義在一個單獨的類之外的MVC（讓說libs文件夾），它永遠不會被用作視圖（我的意思是，我永遠不會調用畫廊頁面本身）。頁面模型將創建圖庫類和控制器將它放在頁面視圖

5. 菜單類/功能將是更通用的功能（因爲它將適用於頁面和類別，如果代碼用於例如購物網站）也可以在一個單獨的區域中定義（可能再次是libs文件夾）。基於在功能菜單設置將在模型被稱爲

上述手段我將具有以下結構

• 模型，視圖，控制器的文件和文件夾的基於標準的MVC方法

• dao lib全部文件夾DAO類

• 類文件夾的lib文件夾，如Page，Menu，Gallery

它看起來公平嗎？我只是急於不要將代碼分散到太多的類中，因爲它意味着更多的「包含」和更多的對象調用。但也許這是要走的路？到目前爲止，我還沒有使用多少MVC方法，並保持文件相當緊湊。想更多地瞭解最佳實踐

Answer 1

這裏有幾件事情需要你來思考一下：

• 你Page類是標準domain object，但PageModel類是不是一個真正的模型。模型是MVC中的一個層。你所說的'PageModel'實際上是一個更高層次的對象，它具有模型層，它創建了pulic-ish接口，以便視圖和控制器可以稍後與模型進行交互，而不公開任何域業務邏輯。我稱這種結構爲「服務」，但應該有一個更好的術語。

• 控制器不應該爲視圖「準備數據」。視圖不是一個愚蠢的模板（或者至少不應該是），它應該是一個填充對象，它負責表示邏輯並且可以處理多個模板

• 看起來你正在借用一些來自HMVC的概念，你應該讀一點關於MVC啓發的模式。

• DAO,Page' class and what you call PageModel的實例都屬於模型層。

• 代碼碎片並不是主要的性能問題，特別是當您通過APC啓用操作碼緩存時。但不成熟的優化是一個嚴重的問題。相反，您應該專注於讓您的代碼易於理解。你可以優化它的工作時間。