繼續探討三層關係

每天的理解都不相同，對於這些東西，騎車回家的路上，浮現在大腦裡~~~

上一篇提到了DAO，Business，UI，提到了MVC，曾幾何時，我們會認為，商務邏輯就是controller，bean（就是與資料庫表對應的實體bean）當作了model，七七八八的開始搭配起來，因為見的東西少，基礎知識薄弱，寫的多了就開始出現一些誤區，當然在實踐中，會慢慢的改變這些錯誤的觀點，因為見的多了，懂的多了。

開始接觸的時候，不知道什麼叫做資料訪問，不知道什麼是商務邏輯，什麼是跳轉控制，就是一個頁面給到後台，一通處理之後，再傳遞給前台頁面，當然這就是一次訪問的過程，我個人覺得這也許就是MVC吧。這是不是也可以解釋Struts是一個輕量級的MVC架構呢？

後來，接觸的多了，處理多了，於是開始把它分層處理了，習慣把資料訪問層提取出來，把主要的邏輯處理提取出來，抽取出一些資料模型，讓原來的幕後處理就留一些跳轉，參數封裝成資料模型的東西。大家有沒有發現，我們做的是在伺服器端的處理做了細化，其實我們一直在操作的還是C的內容，而這裡的資料訪問層就是DAO了，邏輯處理就是商務邏輯層，原來的那個東西就成為了表現層了。

那有人會想到，不是還有模型麼，它屬於什麼呢？它就是DTO，資料轉送對象，承載的是伺服器與用戶端之間互動的對象。這個時候，大家有沒有想到我們曾經用的bean這個東西，是不是有點偏差了。那麼與資料庫對應的實體bean是什麼呢？它就是持久化對象PO，它是怎麼變化出來的呢。

當接收到一個請求的時候，我們需要得到一個資料轉送對象，這個對象由多個業務對象加一些其他資訊組合起來，所以我們調取商務邏輯層的對象，擷取業務對象，業務對象是由多個持久化對象拼起來的，這個時候我們就用到了PO的對象，每一次對資料庫的操作，都對應著關係與對象之間的相互轉換，所以PO就是完成這樣的任務了。綜合看來，DTO分析處理，拆分到BO，BO分析拆分，得到多個PO，然後我們將PO按照商務邏輯與資料庫互動的這麼一個過程，而同一個商務邏輯下，常常又存屬在一個事務中。按照棧的思路，DAO先做處理完畢後，返回到商務邏輯層，再形成DTO，到達表現層，回饋給請求使用者。

以上是我今天想到的一點點小東西，積攢起來，希望大家多多指點~