進行分析之前，我們先來複習一下物件導向。
物件是要進行研究的任何事物。
類是具有相同或相似性質的物件的抽象。
物件導向的要素：抽象,封裝、繼承、多型。
物件導向目的是：如何分配職責。
物件導向設計原則(高內聚低耦合)：
單一職責原則 (srp) 乙個類，只有乙個引起它變化的原因。
開放-封閉原則 (ocp)(對外)可擴充套件，(對內)不可修改。
李氏替換原則 (lsp) 子型別必須能夠完全替換其父型別。
依賴倒置原則 (dip) 要依賴於抽象，不要依賴於具體。
介面隔離原則 (isp) 使用多個專門的介面比使用單一的總介面好；
合成/聚合復用原則 (composite/aggregate reuse
principle，carp)在乙個新的物件裡面使用一些已有的物件，使之成為新物件的一部分；新的物件通過向這些對的委派達到復用已有功能的目的。
最小知識原則(principle of least knowledge，plk，也叫迪公尺特法則)不要和陌生人說話。
在web應用中，我們通常使用mvc分層架構模式來將職責分離。
mvc模式的目的是實現一種動態的程式設計，使後續對程式的修改和擴充套件簡化，並且使程式某一部分的重複利用成為可能。除此之外，此模式通過對複雜度的簡化，使程式結構更加直觀。軟體系統通過對自身基本部份分離的同時也賦予了各個基本部分應有的功能。
控制器(controller)- 負責**請求，對請求進行處理。 檢視(view) - 介面設計人員進行圖形介面設計。
模型(model) - 用於封裝與應用程式的業務邏輯相關的資料(屬性)以及對資料的處理方法(行為)。
按照這樣的定義，模型是傳說中的領域模型的實現類，實現業務邏輯，但資料訪問層是不屬於模型的。
我們mvc中的模型可以定義為領域邏輯。
領域邏輯有多中架構模式，如：
事務指令碼： 使用過程來設計業務邏輯，每個過程處理來自表現層的單個請求。
領域模型： 合併了行為和資料(屬性)的領域物件模型。
表模組： 處理某一資料庫表或檢視中所有行的業務邏輯的乙個例項。
服務層： 通過乙個服務來定義應用程式邊界，在服務層中建立一組可用的操作集合，並在每個操作內部協調應用程式的響應。
表模組模型是把領域模型和資料訪問合併起來了。
事務指令碼是面向過程的，不利於分配職責。
服務層是php之外的東西了。
如果專案相對較小，業務邏輯很簡單，也是用一種固定的資料庫(如mysql)，就不需要分業務邏輯層和資料訪問層，可以選擇表模組模式組織領域邏輯。
如果專案的功能會隨著時間越來越多，需求不好控制，我們需要更多的考慮到減少依賴和明確職責，這樣我們使用領域模型的領域邏輯架構模式來作為mvc中的m層，對物件的屬性和行為進行描述，另外新增乙個資料訪問層給業務邏輯提供資料。
在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中的模型是對領域模型的實現，對業務物件的屬性和行為負責，組成業務邏輯層，通過表資料入口模式對業務邏輯層進行支援。
簡單設計模式實現業務邏輯與流程邏輯的分離
在企業應用系統開發中，特別是涉及到多部門協同作業的情況，業務流程是最難確定下來的，應用系統開發過程中和應用系統上線後流程經常會發生變化。如何採用有效，合理成本的方式來處理這種現象呢？如果做到在應用系統開發中業務邏輯與流程邏輯分離，即可達到業務流程不確定的情況下的不影響開發進度，同時有可以提公升應用系...
簡單設計模式實現業務邏輯與流程邏輯的分離
在企業應用系統開發中，特別是涉及到多部門協同作業的情況，業務流程是最難確定下來的，應用系統開發過程中和應用系統上線後流程經常會發生變化。如何採用有效，合理成本的方式來處理這種現象呢？如果做到在應用系統開發中業務邏輯與流程邏輯分離，即可達到業務流程不確定的情況下的不影響開發進度，同時有可以提公升應用系...
老生常談 表現邏輯與業務邏輯的分離
表現邏輯和業務邏輯的分離是老話題了,近日恰好遇到此相關問題,便把自己心得拿來塗鴉.表現邏輯和業務邏輯的具體定義不再敘述,我各舉乙個例子,畢竟具體的例子更容易讓人明白.比如,web頁面上要顯示新聞的列表,要求奇數行顯示為紅色,偶數行顯示為白色,這樣的就是表現邏輯 再看這樣的需求 web頁面上列出使用者...