摘要：為什麼我們就要使用 n（物理）層體系結構來構建系統？這是一篇基礎性的文章，介紹了人們對於軟件的一種理念，即當我們面對新項目時往往將系統明確地分為三個物理層次：表現層、業務邏輯層和數據訪問或資源層。然而，對於循規蹈矩的做事方式應當重新審視。
有些事物是如此堅定地挺進了我們的通俗文化之中，以至於不發生災難性的事故就無法將其擯棄，即使它們早已不能適應我們的生活。這樣的例子在法律界比比皆是，在當今時代或其他時代美國的市、州甚至聯邦政府針對無意義的書籍都有相關的法律（據說，在亞利桑那州的某個小鎮上，在公路中間倒車是違法的）。這不禁使人聯想到一個老笑話：
一個剛結婚的男人看到妻子正在准備晚餐要吃的烤肉。他吃驚地發現，妻子在將肉放到烤盤中前，分別在兩端切掉了大約兩英寸的肉，然後扔掉。而當男人對妻子的這一行為表示驚訝時，妻子回答道“這會使肉的味道更好。而且，我的媽媽也總是這樣做”。他好奇地給岳母打了電話，問她是否也切掉烤肉的兩端，以及這樣做的原因。“因為這會使肉的味道更好。而且，我的媽媽也總是這樣做”。男人決心找出這個習慣的源頭，於是又給妻子的外婆打了電話，當外婆回答她在准備烤肉的時候也要切掉肉的兩端時，男人又接著問為什麼。外婆立刻回答說“因為我的盤子太小了，裝不下整塊肉”。
毫無疑問，對於這種明顯的循規蹈矩的做事方式應當重新審視。但遺憾的是，其他情況並不都如此顯而易見。
例如，為什麼我們就要使用 n（物理）層體系結構來構建系統？這是一篇基礎性的文章，介紹了人們對於軟件的一種理念，即當我們面對新項目時往往將系統明確地分為三個物理層次：表現層，用以處理所有用戶輸入和數據顯示問題；業務邏輯層，存放所有“業務邏輯”（本身是一個完全無定性的名詞，可准確表示說話者希望其表達的意思）；數據訪問或資源層，存放用於檢索、修改或存儲數據的所有代碼。當被問道為什麼要這樣做時，許多人只能說出最普通的答案，“因為我的老師（或前任主管或剛讀過的一本書）總是這種做”。與普通的進程內調用相比，跨物理層通信會帶來高達三到六個數量級的巨大性能成本，兩者的差距就相當於一個是到樓下雜貨店而另一個是到冥王星。（請參閱《Effective Enterprise Java》（有效的企業 Java）第 17 條）。僅僅因為媽媽總是這樣做，我們就要丟掉好肉… 嗯 CPU 周期嗎？
歸根結底，請記住以物理分層的方式構建應用程序並不是開發人員的唯一選擇。舉個例子，想想 UNIX 開發人員早已熟知而 .Net 開發人員隨著 Microsoft Windows PowerShell 的即將推出才開始領悟到的一個真谛：將小部件分割成可以互饋的片段可以創建出一些功能極強的合成工具，避免了用來維護復雜應用程序所需的相應復雜性。例如，對一般的 C# 或 Visual Basic 語言開發人員而言，創建一個能夠在文本文件中搜索並替換某個字符串序列的工具可能是件容易的工作，而這對於掌握 PowerShell 的人則更加顯得微不足道，因為它只需串聯幾個“cmdlets”：其中一個用於遍歷文件，另一個用於搜索文件內容並用新文本替換所搜索的文本，第三個用於將新內容寫入磁盤。這是一個非常好的模型。具體而言，由於每個組件都能夠專注於特定的任務（遍歷、搜索、寫入），從而簡化了它們的維護和設計工作。
在匆忙地對 n（物理）層模型做出審判之前，它應該得到一次救贖的機會。對於初學者，我們可以對過於通用的“n 層”一詞的使用稍加重新界定，並指出“物理層”和“邏輯層”的重要區別。（請參閱 Martin Fowler 的《Patterns of Enterprise Application Architecture》（企業應用體系結構的模式），閱讀關於這一主題的完整論述。）
“邏輯層”是對軟件的邏輯分割，是在開發人員級對各關注點的基礎分割，這樣我們可以更加容易地劃分系統的職責。這在 [POSA1] 中有進一步的論述。在這本書中談及邏輯層模式時講到，使用邏輯層“有助於構築可以分解為子任務組（每組子任務處於某個抽象級別）的應用程序”。換句話說，它是對各關注點的典型分割方式：將企業系統中所涉及的各種任務（包括檢索數據、存儲數據、針對數據執行業務規則、顯示數據、搜集輸入值等等）分割為組件或子節，以便我們能夠更加輕松地跟蹤在何時何處發生了什麼。當然，最為常見的方式是將任務分為“表現”、“邏輯”和“數據訪問”（邏輯）層。但請注意，我們並沒有立即假定每個邏輯層將在“哪裡”運行，目前還沒有。
而另一方面，“物理層”是硬件（通常是某種形式的計算機）的物理分層，我們系統的一部分或全部可以運行於其上。傳統的客戶機/服務器計算（即寫入可以針對運行於單獨服務器上的數據庫執行 SQL 語句的程序）是一個由兩個物理層構成的系統。
