這重構版的機房的計畫早就開始，但開始的僅僅是計畫，卻遲遲沒有行動的意思，於是頻頻地徘徊著，迷茫著。這都過去三個星期了，每次的停滯不前我都有自己的理由，但是我應該從心底裡明白「成也三層，敗也三層」。用三層對機房收費進行重構是乙個坎兒，這就是乙個對我們的的考驗，挺過去的就是通往下一站的乘客，沒過去應該就和程式設計無緣了吧。
首先，三層分為ui層、bll層、dal層。
其次，ui層，說明白點就是我們平時程式中需要用到的介面，而也就是離使用者最近的；bll層就是俗稱的邏輯層。提到邏輯，大家都懂，就是程式的思維過程，一步一步怎麼往下走，怎麼實現這樣的思想過程。dal，也就是資料訪問層，顧名思義，就是幫助我們寫一些語句來訪問資料庫。
但也就是這對三層匱乏的理解，我的機房重構一直在原地踏步。昨天晚上，我們兩個溝通了一下，究竟是什麼導致我面對機房卻全無興趣。最重要的是我沒有真正的理解三層，那麼我也就不會將三層用到我的機房中，自然而然就不會往下進行，但眼看著別人都一步一步往前走，我的心裡也不是滋味。另一方面，我現在還是有一種毛病，總為自己的一些時間拖延找一些很牽強的藉口，我的番茄中機房重構的任務連續好幾天一直是6/0，但更大的毛病是我會心裡一直不舒服。。。。。
最後，它們之間的引用關係：ui引用bll，bll引用dal，而它們三個又都必須引用同乙個叫做model的實體類。
通過昨天的分析，我對三層算是有了多一點的理解。
首先，三層是為了解耦，切實履行」高內聚，低耦合「的思想，此話怎講？三層中每一層與《大話設計模式》中講到的「單一職責原則」，各司其職：ui負責介面，bll負責邏輯，dal負責一些對資料庫的增刪改查的語句，model呢，就是將某乙個介面對應的資料表中的資料取出，去和介面中輸入的那些資訊進行對比。而model的數量大於等於資料表的數量，model中的方法等於需要用到的資料表的欄位名。如下圖，登入窗體的model中有username和password兩個方法。
這樣，一改之前邏輯、資料庫語句和介面「大雜燴」的局面，將所有的工作進行分類整合，斷開介面和資料庫訪問之間的直接聯絡，取而代之的是bll層使用自己的邏輯呼叫ｄａｌ中的一些方法和定義，然後結合model中的方法實現介面所要求的操作。
而這裡的引用是幹嘛的，為什麼要讓三個層之間實現引用呢？
我是這樣理解的：因為程式的**已經被分為三部分，任意乙個部分都不能直接構成整個程式，所以，引用呢就是使兩個層之間產生聯絡，當ｕｉ需要使用ｂｌｌ中的一些方法和變數名稱的時候確保可以順利使用，而不是被限制或者自己重新命名，不引用自己重新命名不就產生冗餘了，也不符合三層的」旨意「啊。所以說呢，引用就像是一種血緣關係，告訴它們三個它們是親兄弟，只有三個人一起才能完成整個程式執行的使命，所以必須在彼此需要的時候出現並且伸出援手。從而一起完成它們的媽媽「三層」交給它們的任務！
這樣一來，當我們需要對原來的程式進行修改，我們只需要輕鬆的對介面、邏輯和資料語言進行小改動，不至於驚動其他功能。因此在實現了解耦這一目標的同時，也達到了程式的可維護性和可擴充套件性的長遠目標。
三層 我眼中的三層結構
從行為型模式命令模式引發的對三層的思考。記得 大話設計模式 中對命令模式的講解。燒烤攤和燒烤店之間的區別。由於客戶和烤羊肉串老闆的 緊耦合 所以容易出錯，容易混亂，也容易挑剔。這其實就是 行為請求者 與 行為實現者 的緊耦合。對請求排隊或記錄請求日誌，以及支援可撤銷的操作等行為時，行為請求者 與 行...
三層架構 之三層擴充套件七層
哎，真心不想在這裡寫這篇部落格，本來三層到七層頂多了也就用兩天時間去分析，結果我用了將近四天，最後我都快崩潰了，還有好多問題都是同學幫我找出來的，真是很是汗顏吶！下面是我三層架構擴充套件成七層架構的uml包圖 之前看別人都是用的vb.net版，我就覺得剛學習了c 語言，就先用c 版吧，結果倒好，兩種...
c mysql三層架構例項 三層架構例項
一 概要 這篇部落格，準備用乙個小demo來介紹應該實現三層架構。三層架構只是分層的一種經典形式，到底分幾層，要依具體情況而定，考慮到系統的複雜程度，和後期的可維護性，完全可以分四層，五層，甚至六層，七層。二 demo 1 實現語言 vb.net 2 需求 學校機房收費系統 中的乙個功能 操作員為學...