PHP MVC＆SQL minus模型

Question

我一直在閱讀關於MVC的幾篇文章，並且有一些問題我希望有人可以幫我回答。

首先如果MODEL是數據的表示，並且其中操縱該數據的裝置，則使用公共接口數據訪問對象（DAO）與抽象的一定程度應該足以滿足大多數任務應該它不是？爲了進一步闡述這一點，假定我的數據的底層存儲機制是MySQL的大部分開發工作，如果我在構建SQL語句時避免了供應商特定的函數（如UNIX_TIMESTAMP）並使用了一個抽象的DB對象，該對象具有在MySQL和PostgreSQL之間移動的公共接口，或者MySQL和SQLite應該是一個簡單的過程。

這裏就是我得到的一些任務，由單一控制器的處理 - （即放在userRegistration）和相當，創造一個模型該任務，我可以得到數據庫對象的實例 - - （即DB :: getInstance（）） - 然後進行必要的數據庫調用來插入一個新用戶。爲什麼有這樣一個簡單的任務，我會創建一個新的模型？

中的一些例子我見過模型創建，而MODEL內有其獲取從訂單表訂單x個，並返回一個數組的SELECT語句。爲什麼要這樣做，如果你在創建另一個循環來遍歷該數組並將其分配給VIEW;恩。 1？

ex。 1：foreach ($list as $order) { $this->view->set('order', $order); }

我想我可以修改返回，所以這樣的事情是可能的;恩。 2.

ex。 2：while ($order = $this->model->getOrders(10)) { $this->view->set('order', $order); }

我想我的觀點是，爲什麼創建模型時，你可以簡單地從你的控制器內進行必要的數據庫調用，使用與普通接口DB對象來訪問數據的假設，如我懷疑大多數網站正在使用。是的，我不認爲這對所有的任務都是實用的，但是當大部分工作都很簡單，不一定需要單獨的型號。現在，用戶發出請求'www.mysite.com/Controller/action/args1/args2'，前端控制器（我稱之爲路由器）傳遞給控制器​​（類），並在該控制器內調用某個動作（方法），然後從那裏創建適當的動作並輸出。

Answer 1

所以我想你想知道是否增加了數據庫訪問對象頂層模型層的複雜性是你想要的方式。根據我的經驗，簡單性勝過了其他所有問題，所以我建議如果你看到一個清楚的情況，那就是沒有模型就可以完成更簡單的工作，並且讓數據訪問發生在控制器的等價物中，那麼你應該去做。

然而，仍然有具有MVC的其他潛在的好處：

• 沒有SQL在所有控制器：也許你決定從不是數據庫（在陣列中其他來源收集數據會話？一個模擬對象，用於測試？一個文件？只是別的東西），或者您的數據庫模式發生變化，您必須查找代碼必須更改的所有位置，您可以查看模型。
• 技能組的分離：你的團隊中的某個人可能擅長複雜的SQL查詢，但在處理php方面並不擅長。然後代碼越分離，越多的人可以發揮自己的優勢（甚至當涉及HTML/CSS/JavaScript方面的事情時更是如此）。
• 表示數據塊的概念對象：正如史蒂芬說，有一個在你作數據庫無關得到了實惠的差，並且是模式無關（所以你（所以你可以MySQL和PostgreSQL之間如果需要的話切換）有一個對象充滿了很好的數據，即使它來自不同的關係表）。當你有一個代表好的數據塊的模型時，你應該能夠在多個地方重複使用該模型（例如，一個人模型可以用於登錄和顯示人員列表）。

我當然認爲MVC任務分離的理想是非常有用的。但隨着時間的推移，我開始認爲使用函數式編程風格來保持類似MVC的分離的替代風格在PHP中可能比全面的OOP MVC系統更容易處理。

Answer 2

MVC背後的想法是在你的邏輯之間有一個乾淨的分離。因此，您的視圖只是您的輸出，而您的控制器是一種與您的模型進行交互並使用模型獲取必要數據以提供必要視圖的方式。但是實際獲取數據的所有工作都將在您的模型上進行。

如果你認爲你的用戶模型是一個真實的人而不是一塊數據。如果你想知道人名叫電話（數據庫）的中心辦公室更容易，並要求提供姓名或只問人，「你叫什麼名字？」這是該模型背後的想法之一。以一種最簡單的方式，您可以將您的模型視爲真實的生物，並且您附加的方法允許您的控制器向這些生物提出一系列問題（IE - 您是否可以查看此頁？您是否登錄？圖像是你嗎？你是否出版？你最後一次修改的時間？）。你的控制器應該是愚蠢的，你的模型應該很聰明。

另一個想法是讓你的SQL工作在一箇中心位置，在這種情況下你的模型。這樣你就不會在你的控制器和最糟糕的情況下浮現你的觀點。

Answer 3

我發現這篇文章解決了我的大部分問題。如果其他人有類似的問題或有興趣閱讀本文。你可以在這裏找到它http://blog.astrumfutura.com/archives/373-The-M-in-MVC-Why-Models-are-Misunderstood-and-Unappreciated.html。