三層架構—簡析
三層學習完了，第一次驗收的時候，自己理解的也不是非常到位，後來又又一次敲了一遍登陸樣例，查閱了一些資料
進行第二次驗收才感覺清晰了很多。之前畫時序圖時我就想過時序圖基本上也是非常好的體現了三層，當時也和別人討
論過這個問題。
直到學完三層後，更加證明了這一點。
以下我將從理論和實踐兩個角度總結一下三層。
理論篇
為什麽使用三層架構？
說白了，分層的目的是想將復雜問題簡單化，也就是面向對象技術所崇尚的“高內聚，低耦合”。當業務復雜到
一定程度。數據存儲在獨立的存儲介質時適合用三層架構。
什麽是三層架構？
通常意義上的三層架構(3-tier architecture)就是將整個業務應用劃分為：表現層（UI）、業務邏輯層
（BLL）、數據訪問層（DAL）。
圖解
表現層（UI）：主要是指人機交互界面。用於接收用戶輸入的數據和顯示處理後用戶須要的數據。
業務邏輯層（BLL）：連接UI和DAL的橋梁。
數據訪問層（DAL）：實現數據庫的增、刪、改、查。
實體類（Model）：不屬於三層的範疇，個人理解的建立實體類的目的是將加載的數據庫中的數據放入當中，
UI、BLL、DAL。哪個須要就從實體類中獲取。封裝數據，避免了傳參數造成的復雜，從而避免了各個層與數據庫的直
接接觸，造成數據交叉。各個層僅僅須要和實體層Model打交道就可以。
點睛
各個層各司其職，僅僅負責自己專屬的功能。提高了內聚性，降低了彼此之間的耦合。Model是數據傳輸的業務數
據模型，不是數據庫中的數據。Model是避免出現數據交而建立的。
怎樣搭建？
優缺點？
長處
1、開發者能夠僅僅關註整個結構中的當中某一層。
2、能夠減少層與層之間的依賴；
3、有利於標準化，能夠非常easy的用新的實現來替換原有層次的實現。
4、在後期維護的時候，極大地減少了維護成本和維護時間
缺點
1、減少了系統的性能。這是不言而喻的。假設不採用分層式結構。非常多業務能夠直接造訪數據庫，以此獲
取對應的數據。現在卻必須通過中間層來完畢。
2、有時會導致級聯的改動。這樣的改動尤其體如今自上而下的方向。
假設在表示層中須要添加一個功能。為
保證其設計符合分層式結構，可能須要在對應的業務邏輯層和數據訪問層中都添加對應的代碼。
3、添加了開發成本。
實戰篇
以下是一個登錄窗口的DEMO
UI層的代碼
<span style="font-family:KaiTi_GB2312;font-size:18px;">namespace LoginUI
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void btnLogin_Click(object sender, EventArgs e)
{
string userName = txtUserName.Text.Trim();
string password = txtPassword.Text;
Login.BLL.LoginManager mgr = new Login.BLL.LoginManager(); //重載BLL層
Login.Model.UserInfo user = mgr.UserLogin(userName, password);
MessageBox.Show("登錄用戶：" + user.UserName);
}
}
}
</span>UI層，人機交互。須要引用BLL和Model層，從代碼中能夠看出UI層不包括不論什麽邏輯推斷的代碼和跟數據庫有關的
代碼。
BLL層的代碼
<span style="font-family:KaiTi_GB2312;font-size:18px;">namespace Login.BLL
{
public class LoginManager
{
public Login.Model.UserInfo UserLogin(string userName, string password) //獲得Model中封裝的數據庫中的數據（UI層中的）
{
Login.DAL.UserDAO uDao = new Login.DAL.UserDAO(); //實例化UserDAO類
Login.Model.UserInfo user = uDao.SelectUser(userName, password);
if (user != null) // 加載成功
{
Login.DAL.ScoreDAO sDao = new Login.DAL.ScoreDAO(); //知道數據庫連接成操作命令
sDao.UpdateScore(userName, 10);
return user;
}
else
{
throw new Exception("登錄失敗。");
}
</span>從代碼中能夠看出BLL層也不和數據庫打交道，沒有SQL語句。
須要引用DAL和Model層。
DAL層代碼
<span style="font-family:KaiTi_GB231<span style="font-family: Arial, Helvetica, sans-serif;">2;font-size:18px;">namespace Login.DAL</span>
{
public class UserDAO
{
public Login.Model.UserInfo SelectUser(string userName, string password) //獲取Model中的表中的數據，返回的是數據模型
{
using (SqlConnection conn = new SqlConnection(DbUtil.ConnString)) //建立數據庫連接
{
SqlCommand cmd = conn.CreateCommand(); //表示要對 SQL Server 數據庫運行的一個 Transact-SQL 語句或存儲過程。 實例化一個接口,用以運行SQL指令
cmd.CommandText = @"SELECT ID, UserName, Password,Email
FROM USERS WHERE [email protected] AND [email protected]";
cmd.CommandType = CommandType.Text;
cmd.Parameters.Add(new SqlParameter("@UserName",userName)); //添加上面數據庫連接中設的兩個參數
cmd.Parameters.Add(new SqlParameter("@Password",password));
conn.Open(); //打開數據庫
SqlDataReader reader = cmd.ExecuteReader();
Login.Model.UserInfo user = null; //默認值是Null
while (reader.Read()) //讀取數據庫中的數據
{
if (user == null)
{
user = new Login.Model.UserInfo(); //當Model是Null的話才載入數據
}
user.ID = reader.GetInt32(0);
user.UserName = reader.GetString(1);
user.Password = reader.GetString(2);
if (!reader.IsDBNull(3)) //假設Email不是Null的話，才幹讀取
{
user.Email = reader.GetString(3);
}
}
return user;
}
}
}
}
</span>
從代碼中能夠看出是直接和數據庫打交道的，沒有跟窗口控件有關的內容。須要引入Model層。
個人小結
分層的目標是為了“高內聚。低耦合”。分層可將復雜的簡單化。當需求須要改變時，你僅僅須要該對應部分而不
用大範圍的改動。分層還提高了可維護性和可擴展性，但並非全部的都要分層，業務邏輯簡單，沒有真正的數據存
儲層這時就不須要分層，假設分層反而會添加復雜度。所以我們尋常在使用時要註意靈活應用。
三層架構—簡析