三層結構的確切定義

我算是糊塗了
沒有任何概念比電腦中的概念要模糊了
有時候,英文是一個意思,被人翻譯後又是一個意思
比如我們常說的三層定義

第一種通俗的理解是
展示層就是像WINFORM或WEBFORM等
商務邏輯層:這個東東是什麼呢,做什麼用呢?我開始的理解是那些DLL
資料存取層:就是資料庫部分了.

但是第一種理解對於我來說,我覺得不太妥,具體有什麼不太妥,也不知道.
無知者無畏,反正我也沒有科班或正式的去學過三層體系,所以,不怕大家笑話,我就胡說八道幾句吧
第二種理解是我最近想的
展示層是指介面部分,例如WINFORM,例如WEBFORM,或者其他一切用於呈現資料外觀的東東
商務邏輯層:這一部分是我以前最糊塗的了,不過,最近接觸了一點ORM的概念受了點啟發,有了一點點理解
我們可不可以這樣想,三層體系就是把資料的儲存,資料的表示和資料的規則分離,這樣一看,所謂商務邏輯(這個字暴生辟呀),就是指資料的規則,也就是說,資料的有效性等等.
至於資料存取層,這一部分,容易理解的多了,就是指用於直接讀取,儲存資料的部分.

我想,這樣說,太生硬,摸不著看不見,但是下面的例子是做過ASP.NET的都遇到過的吧.
舉個例子來說.
有一個表CUSTOMER,你要負責將此表內容呈見給瀏覽者.同時,提供另一個介面給資料管理者管理資料.
呈現給瀏覽者的資料是一個WEBFORM形式,呈現給資料管理者的是一個WINFORM形式.
不管怎麼說,在展示層部分,這個資料使用了截然不同的兩種表現形式.
但是資料來自何方呢?直接從資料庫提取然後就顯示嗎?可能不行,對於WEBFORM的介面來說,你可能需要對資料進行一些加工.比如,把資料中的客戶的LASTNAME和FIRSTNAME合并等.更有可能,對於管理資料的人來說,你需要處理一下錄入的資料,驗證一下這些資料是否合乎一些規則,比如,性別必需為男/女,比如,年齡不能大於20,有了這種需要,就意思著你不是需要從資料介質中提取的未經處理資料,或者你不是直接把錄入的未經處理資料存入到資料介質中.你需要一個對資料進行驗證,加工,變形的過程.所以,我想,商務邏輯層處理的就是這部分?

而資料存取層呢,一提到他我們就以為是關聯式資料庫.其實不然,資料存取層是存取資料庫/XML資料/其他任何可訪問資料的代碼.說到這些,微軟的DAAB簡化的就是資料存取層了.
以前我們要做一個資料存取層,就要建串連,建COMMAND,建一堆東東,然後還得記著統統關掉,及時釋放.現在,DAAB簡化了這部分的工作,使資料庫的串連,查詢,關閉自動化.
但DAAB取代不了資料存取層,因為它是抽像的,對應於每一個具體的實用(例如一個表),你必須去寫一個具體的資料存取層.
另外,看了ORM外,我還有一個感想,以前,我做的東東裡,都是先建好資料庫,然後再去寫代碼.寫得很乏味,後來,用起CODESMITH來自動產生.CODESMITH用起來很好.可是,看了ORM,大家都認為資料庫是ORM的附加產物.也就是說不是由D到O,而該由O到D.這與我之前的過程恰恰相反.但仔細想想,確實該由O到D.
為什麼呢?做過由資料庫產生資料訪問層的人都會有一個問題,就是,如果以後需要改動資料庫中的一個欄位,比如加入一個欄位,刪除一個欄位,將會引發一連串的改動,包括會改動到涉及此欄位的資料存放區類以及商務邏輯類,改起來,很容易遺漏.
假如按上面的三層理解法,我們可以認為資料對象是中心.商務邏輯對其進行修飾及驗證,一方面它又被呈現,一方面它又被持久化.因此,我們可以先去設計商務邏輯層(就是表示對象的了),例如上面的例子:
我們先建立名為CUSTOMER的對象.為其定義若干個屬性,每一個屬性工作表示CUSTOMER的一個欄位.然後再為此CUSTOMER建立資料存取層.至於資料庫,我想,有沒有可能直接由CUSTOMER類的定義產生呢?

如果這樣,似乎更符合自然規律,想想,我們建立CUSTOMER對象,先用類表示出此對象.為其添加屬性,為其添加行為,然後,再產生此對象的持久形式.是不是很理想呢?

當然,以上是我的理解.我至今仍不清楚真正的三層究竟該如何定義.
我也不清楚ORM跟我第二種理解究竟有多大偏差.
更為重要的是,我迫切的想知道,有沒有一種從O(對象)到D(資料)的開發方法.因為,業務對象和資料庫聯絡實在太緊了
不管是由D到O還是由O到D,總要解決一個問題,那就是,當業務對象發生變化時,該如何去保持其資料存放區的同步表現呢,怎樣才讓兩者更離散一些,以解決後續維護帶來的問題呢?

希望高手指點