1、面向對象能給我們什么？
進行分析之前，我們先來復習一下面向對象。
對象是要進行研究的任何事物。
類是具有相同或相似性質的對象的抽象。
面向對象的要素：封裝、繼承、多態。
面向對象目的是：如何分配職責。
面向對象設計原則：
-
單一職責原則 (SRP) 一個類，只有一個引起它變化的原因。
-
開放-封閉原則 (OCP)(對外)可擴展，(對內)不可修改。
-
李氏替換原則 (LSP) 子類型必須能夠完全替換其父類型。
-
依賴倒置原則 (DIP) 要依賴於抽象，不要依賴於具體。
-
接口隔離原則 (ISP) 使用多個專門的接口比使用單一的總接口好；
-
合成/聚合復用原則 (Composite/Aggregate Reuse Principle，CARP)在一個新的對象里面使用一些已有的對象，使之成為新對象的一部分；新的對象通過向這些對的委派達到復用已有功能的目的。
-
最小知識原則(Principle of Least Knowledge，PLK，也叫迪米特法則)不要和陌生人說話。
2、業務邏輯層
在web應用中，我們通常使用MVC分層架構模式來將職責分離。
MVC模式的目的是實現一種動態的程序設計，使后續對程序的修改和擴展簡化，並且使程序某一部分的重復利用成為可能。除此之外，此模式通過對復雜度的簡化，使程序結構更加直觀。軟件系統通過對自身基本部份分離的同時也賦予了各個基本部分應有的功能。
-
控制器(Controller)- 負責轉發請求，對請求進行處理。
-
視圖(View) - 界面設計人員進行圖形界面設計。
-
模型(Model) - 用於封裝與應用程序的業務邏輯相關的數據(屬性)以及對數據的處理方法(行為)。
按照這樣的定義，模型是傳說中的領域模型的實現類，實現業務邏輯，但數據訪問層是不屬於模型的。
我們MVC中的模型可以定義為領域邏輯。
領域邏輯有多中架構模式，如：
事務腳本： 使用過程來設計業務邏輯，每個過程處理來自表現層的單個請求。
領域模型： 合並了行為和數據(屬性)的領域對象模型。
表模塊： 處理某一數據庫表或視圖中所有行的業務邏輯的一個實例。
服務層： 通過一個服務來定義應用程序邊界，在服務層中建立一組可用的操作集合，並在每個操作內部協調應用程序的響應。
表模塊模型是把領域模型和數據訪問合並起來了。
事務腳本是面向過程的，不利於分配職責。
服務層是PHP之外的東西了。
如果項目相對較小，業務邏輯很簡單，也是用一種固定的數據庫(如MySQL)，就不需要分業務邏輯層和數據訪問層，可以選擇表模塊模式組織領域邏輯。
如果項目的功能會隨着時間越來越多，需求不好控制，我們需要更多的考慮到減少依賴和明確職責，這樣我們使用領域模型的領域邏輯架構模式來作為MVC中的M層，對對象的屬性和行為進行描述，另外添加一個數據訪問層給業務邏輯提供數據。
3、數據訪問層
在martin fowler的《企業應用架構模式》介紹了4種數據源架構模式：表數據入口、行數據入口、活動記錄、數據映射器。此外還有ResultSet、 Metadata等模式。
(1)表數據入口(Table Data Gateway)：充當數據庫表訪問入口的對象。一個實例處理表中所有的行。
(2)行數據入口(Row Data Gateway)：充當數據源中單條記錄入口的對象。每行一個實例。
(3)活動記錄(Active Record)：一個對象，它包裝數據庫表或視圖中某一行，封裝數據庫訪問，並在這些 數據上增加了領域邏輯。
(4)數據映射器(Data Mapper)：在保持對象和數據庫彼此獨立的情況下在二者之間移動數據的一個映射器層。它能夠在內存對象和數據庫中傳遞數據並保持他們彼此獨立，以分離領域與數據源。
活動記錄集可以使用在不分業務邏輯層和數據訪問層的情況。
最理想的情況下是使用數據映射器模式，使用ORM層，業務邏輯層只出力領域中的行為，增加VO模型對對象的屬性進行描述和validate，通過DAO訪問數據庫。這樣就能徹底的面向對象了，在業務邏輯、數據訪問、視圖中都直接操作直觀的VO模型類。但是回到現實中，我們發現這樣做起來把事情復雜化了。
我們PHP程序員對SQL語句就像是C/C++程序員離不開指針一樣，使用sql語句非常靈活，更利於性能優化。絕大多數情況下，我們的系統用什么數據庫都是預先定好了的，轉移的可能性非常少。而且我們用面向對象分析的時候，只分析到業務邏輯層(領域模型)。我們只用kv數組/對象替代VO對象在PHP中不論是數據存貯還是數據分析和處理，都更靈活。因此，由語言本身決定，表數據入口模式更適合做PHP的數據訪問層。
綜上，我們MVC中的模型是對領域模型的實現，對業務對象的屬性和行為負責，組成業務邏輯層，通過表數據入口模式對業務邏輯層進行支持。