因為最近有點忙，這個月沒能保證每月四篇的部落格更新量。進度斷層也有點大。上篇部落格還總覽設計模式呢，這篇就直接初探三層架構了。不過沒關係，學習從來不是一次性的事情，以後肯定還會重複遇到，重複學習。 沒介紹到的設計模式和c#
還是老樣子，認識乙個新事物，先從三個方面來考察，是什麼，為什麼，怎麼做。
【我的理解
】聯想一下atm
機，ui
層就是我們看到的部分，我們對它的要求就是使用者看著舒服（介面友好），能存錢能取錢（傳入傳出引數）。但是你要設計乙個取款機，使用者能直接伸手把錢掏出來，那你這設計師就有點不著調了，是不？（
ui不與資料庫直接互動，不儲存邏輯）。
（引用bll）
bll層 就是
atm機控制機器訪問錢的考，像要不要吐給你錢，什麼情況下吐，吐多少，這個樣子。。你和機器互動時的邏輯思考都在
bll層。這個部分就負責處理ui和
dal傳來的資料，看看錢數對嗎（執行邏輯指令）具體拿錢的工作交給
dal（引用dal）
dal層 我就是一勞力，
bll讓我拿啥，我拿啥。
bll傳回指令，拿
10張，我就遞十張出去（對資料進行增刪改查）
實體層 這一層的作用就是在三層之間用統一的物件來對資料進行描述。就像三層間的普通話。用這層中的物件描述資料，同時存在於其他三層。
（有需要的情況下，其它三層都可以引用實體層）
一時好奇把這個寫上了， 沒找到相關資料。。 有興趣的朋友自己找找吧。
1、開發人員可以只關注整個結構中的其中某一層；
2、可以很容易的用新的實現來替換原有層次的實現；
3、可以降低層與層之間的依賴；
4、有利於標準化；
5、利於各層邏輯的復用。
6、結構更加的明確
7、在後期維護的時候，極大地降低了維護成本和維護時間
1、降低了系統的效能。這是不言而喻的。如果不採用分層式結構，很多業務可以直接造訪資料庫，以此獲取相應的資料，如今卻必須通過中間層來完成。
2、有時會導致級聯的修改。這種修改尤其體現在自上而下的方向。如果在表示層中需要增加乙個功能，為保證其設計符合分層式結構，可能需要在相應的業務邏輯層和資料訪問層中都增加相應的**。
3、增加了開發成本
從bll
層開始入手分析，理清業務邏輯 ，需要和資料庫打交道的寫進
dal層， 顯示給使用者的寫進
ui。 實體層直接從資料庫對映。
bll層入手：需要完成的業務邏輯是將資料層驗證傳出的結果反饋給
ui層，同時如果成功登入，使用者獲得十分。
**：
namespace login.bll
else }}
}
， 所以從實體對映過來
namespace login.model
public string username
public string password
public string email}}
namespace login.dal //鏈結字串
}
namespace login.dal}}
}
namespace login.dal
user.id =reader.getint32(0);
user.username =reader .getstring (1);
user.password =reader .getstring(2);
if (!reader.isdbnull (3))
}return user;}}
}}
【總結】
核心還是解耦合， 把資料和邏輯、顯示分別放到不同的層裡。維護自然更方便。。
三層架構 之三層擴充套件七層
哎，真心不想在這裡寫這篇部落格，本來三層到七層頂多了也就用兩天時間去分析，結果我用了將近四天，最後我都快崩潰了，還有好多問題都是同學幫我找出來的，真是很是汗顏吶！下面是我三層架構擴充套件成七層架構的uml包圖 之前看別人都是用的vb.net版，我就覺得剛學習了c 語言，就先用c 版吧，結果倒好，兩種...
C 學習之三層架構例項
大家都知道三層架構分為 1，表示層 ui 2，業務邏輯層 bll 3,資料訪問層 dal 下面咱們用乙個簡單的例項，實戰三層架構 首先建立乙個空白的解決方案，新增如下專案以及檔案 2.新增classlibrary專案，命名為bll，新建class型別檔案userbll.cs 3.新增classlib...
C 專案之三層架構總結
二 正文 1 顯示層 ui 通俗講就是展現給使用者的介面，即使用者在使用乙個系統的時候他的所見所得，這裡我就先簡單的理解為主要就是軟體的窗體介面類。ui作用 向使用者展示現特定業務資料 採集使用者的輸入資訊和操作 將有需要的資訊在顯示曾顯示出來。ui設計原則 使用者至上，兼顧簡潔 2 業務邏輯層 b...