我有一個具體的問題，可以使用一般的答案......當在PHP中構建多層應用程序時，一切都必須在業務邏輯層完成，或者任何層都可以工作......例如，讓我們假設我正在構建一個應用程序，它在表示層上顯示用戶信息（來自數據庫）。我應該使用業務層簡單地將數據傳遞到表示層，還是直接從表示層獲取數據庫中的信息？如果只使用表示層來呈現數據，那麼訪問器層只是用來獲取數據，而所有的工作都是在業務層完成的？另外，談到不同的層次，最好是在程序上做事情，或者使用OOP（比如使用includes來顯示模板vs使用類來包含模板，使用類或函數來程序化地驗證數據vs從數據庫獲取數據的類等）多層在PHP ..正確的方法？
正如你所看到的，我試圖理解事情是如何工作的，以及做事的最佳方式。話雖這麼說，如果您有任何意見或任何關於這個問題的一般技巧......請讓他們..
感謝
Web應用程序和N層很有趣，主要是因爲N層的概念隨着JSON和AJAX或Flash和XMLRPC的廣泛採用而擴展。這chart on Webopedia顯示一個交錯的藍線，表達這個好。總結一下：您的業務，訪問者和表示邏輯不僅可以存在於服務器上，而且在某些情況下也可以存在於瀏覽器中。然而，N層的意圖是可分離性。如果您需要更換UI或數據庫，或添加其他UI，則不應影響業務邏輯。這就是決定你的API的原因 - 預計你的HTML和CSS在Flex中被拋棄的日子，並且MySQL被Oracle更換。
這是需求確定的，在我使用的一些Web應用程序中，同時使用N層的變體。以LyrisHQ爲例（電子郵件ASP）。他們有一個客戶Web應用程序。最近，他們盯着他們的基於Flash的應用程序。很明顯，這會向瀏覽器傳送大量數據，並且可能在Flash UI中複製了一些業務邏輯。但是，他們必須保留兩份申請，因爲任何一份申請對於不同（和重疊）的要求都是必需的。
最常見的PHP應用程序不考慮將大量未格式化的數據傳送到瀏覽器。但是，如果你是，這會很快告訴你如何設計你的API。很可能，除了類似於PHP演示文稿模板使用的內部控制器類以外，您還需要可以與XMLRPC，REST或SOAP交談的控制器。這將嚴格意味着一個簡單的Web登錄頁面，您將擁有一個與LoginController類交談的登錄表單的PHP模板。 XML接口同樣會使用相同的LoginController類。就像你會認爲你會把SQL寫入Ajax請求一樣，你會嚴格避免在你的演示文稿模板中寫入查詢。
業務層可以更嚴格或更不嚴格，因爲通常不需要切換數據庫後端品牌。在嚴格的N層設計中，您的業務對象如何與數據庫進行交談就好像您可以從MySQL切換到MS SQL，而無需重寫業務層。有時這是通過爲每個表（表網關），每行（活動記錄），每個連接或每個事務建模對象完成的。這就是PDO或PHP-ADO這樣的東西有用，但不足以完全隔離的地方。像Hibernate這樣的Java中的ORM /持久層通常通過提供對象查詢語言（OQL）來演示更好的這種隔離。
我自己，我目前正在進行從基於MySQL的PHP應用程序到MS-SQL的後端轉換。該應用程序只使用過直接的SQL查詢。設想一下如何選擇如何在一個類中進行一系列查詢，或者抽象它們，或者進行子類化，並且希望不會改變業務邏輯。至少，你會希望所有的SQL調用都是間接的。 （S.O. post on PHP ORM。）
最後，對於您關於面向對象的問題：使用它如何必須滿足您的要求。我個人的技巧是從PHP演示模板中的邏輯開始，花幾分鐘時間讓團隊滾動，很快我會將其重構爲一個類和一個模板。如果我有共同的想法，我會將例程分成共享類，努力保持DNRY原則。 （A S.O. post on that here. OOP不是N層設計的基本要求，DNRY對於保持代碼的可維護性非常重要，通常截止日期和範圍轉移會摧毀一個API，重構它直到你得到你需要繼續去的東西。打賭OOP將幫助你到那裏
我曾經讀過的東西說大模型（業務層）應優於大的控制器（訪問器層）。
另外：它確實取決於該項目。在我看來，使用面向對象的一切並不總是有意義的（可能不是每個人都會同意的），尤其是在像PHP這樣的腳本語言中，它往往更容易簡單地將驗證器作爲函數來使用...
我同意Franz說過，特別是關於比較大的控制器更喜歡更大的模型..你也可以使用經驗法則來區分代碼應該去的地方：如果它與UI結構/流有任何關係，把它放在控制器中;如果它是純粹的商業邏輯，它會在模型中..
我會補充說，作爲一個Java開發人員，在測試PHP水域之前有很多Struts經驗，我花了一段時間才明白如何將MVC的想法應用於腳本語言..我個人發現使用像CodeIgnitor這樣的系統幫了很多..它提供了框架，很像Struts，並且鼓勵了良好的MVC模式..
我絕對建議你不要有表示層中的數據庫調用會失敗其目的。
multi-tier architecture有不同的方法，他們有不同的建議。
我一直在使用的Zend Framework通常是Fat模型/ Thin控制器變體的形式。
如果找到這篇文章Notes on Choosing a PHP Framework比較（在本例中）將CakePHP與Zend Framework進行比較。
我的觀點中最大的區別是CakePHP採用的convention-over-configuration方法，它與Zend Framework中的配置焦點非常不同。
通過使用一個框架，如果實現一個多層體系結構很有意義，你的方式被迫或至少推入使用OOP，這不是一件壞事。
當然，你可以實現一個純粹功能調用的三層架構，但根據我的經驗它不能很好地擴展。
對於一個網站來說，MVC模式由於層次交流的方式而有所不同，這是一個不錯的選擇。
「正常」三層架構與MVC模式之間的區別在於，該視圖可以訪問控制器和模型層，其中表示層只能訪問3層架構的邏輯層，一級拱門。
我的世界是這樣的：
DB1 < - 型號1提供存取 功能，數據完整性，業務 規則，這組數據DB2 < - 模型2 提供存取功能，數據 完整性，業務規則 數據集
控制器：控制數據流到 視圖，過濾器/組織來自 視圖的數據。實施 給定應用程序的業務規則。知道 業務規則之間模型。
觀看次數：沒有什麼比模板 顯示數據提供的 控制器。將所有數據傳送至 控制器。不知道 模型1或模型2或業務 管理它們的邏輯。
實際上，它看起來不像原始問題中的標籤之一的MVC模型。但仍然是一個有趣的觀點。 – 2009-11-09 07:05:40
我推薦做一些關於設計模式的研究，因爲這是你的謎題的缺失部分。有許多PHP特定的書籍涵蓋了這個主題（來自APress的很好）以及設計模式的「聖經」："Design Patterns: Elements of Reusable Object-Oriented Software"
爲什麼這次被拒絕？在設計模式的背景下，他不會從他嘗試使用的框架中做出任何事情。 – xentek 2010-03-02 04:54:51
讓我們等待Doctrine2更穩定的版本
它正在與開發持久性 - 無知的領域對象哲學。在這個框架的幫助下開發多層應用程序會容易得多。
是的，是的，是的。 Go框架;） – Franz 2009-11-08 00:50:19