張生和崔鶯鶯說一波三折。最後有情人終成眷屬。但人的生命是真實的。更妙的是人沒房沒車沒好；所以最後張翠鶯鶯要求入職準備禮，聘禮符合自己的要求。就嫁給張生；假設聘禮不和自己的心意，就出家削髮為尼。一輩子不談婚事！以此為故事背景今天就談一下三層的學習。
崔鶯鶯想要明媒正娶，在古代男女之間是不直接接觸的，所以張生請了王婆來給保媒。王婆年事已高不能幹體力活，她找了個挑運工幫她挑聘禮。從自己的媒人錢裡給挑運工支付工錢。此為故事中的主要任務，以下介紹一下他們在三層中扮演的角色。
三層的劃分目的是為了高內聚低耦合的思想，所以分的層次也說法不一，通常劃分為表現層（ui）、業務邏輯層（bll）和資料訪問層（dal）。
1、表現層（ui）：通俗講就是展現給使用者的介面。即使用者在使用乙個
系統的時候他的所見所得。
2、業務邏輯層（bll）：針對詳細問題的操作，也能夠說是對資料層的操作，對資料業務邏輯處理。
3、資料訪問層（dal）：該層所做事務直接運算元據庫，針對資料的增添、刪除、改動、查詢等。
故事中人物扮演角色：張生（ui）,王婆（bll）,崔鶯鶯（dal）。剩下挑運工來扮演實體層。實體層嚴格的來說不算是一層。我們更喜歡叫它實體類。它用來儲存資料在三層中的上躥下跳，跟全部的層都能打交道。
以下我們就看看張生和崔鶯鶯究竟能不能喜結連理吧！
男女之間的事情往往是女方比較靦腆(當然不能排除當今社會的女漢子)，所以張生要主動請王婆幫她下聘禮（u層要引用b層）。王婆要帶著聘禮去找崔鶯鶯下聘，前面說了女方靦腆所以王婆要主動把聘禮送過去，才幹知道是不是崔鶯鶯想要的禮物（b層要引用d層）。挑運工跟著王婆挑著聘禮穿梭在張生和崔鶯鶯之間。所以張生、崔鶯鶯、和王婆都要依賴挑運工（三層都要引用實體層）。
假設王婆帶著聘禮去了，正和崔鶯鶯的意願，那麼這樁親事就算成了，假設崔鶯鶯見到聘禮不合心意，那麼就僅僅能出家了！
//u層**
private void button1_click(object sender, eventargs e)
else }
//b層**
public bool xiapin(string giftname)
else
}
//d層**
public 挑.運工 .giftinfo selectgift(string giftname)
gift .giftname = reader.getstring (0);
}return gift;}}
//實體層**
public class giftinfo
}
可惜的是挑運工心術不正。把王婆打暈後帶著聘禮逃之夭夭了。張生能拿著當初兩人的定情信物「口脂五寸」去下聘：
哎！現實就是這麼殘酷！
第三次結對作業（崔亞明 陸桂鶯）
這個作業要求在 作業要求的鏈結 這個作業的目標 根據要求畫出活 並說明，用記錄 隊員1 211806313 隊員2 211806398 用例編號 優先順序用例名稱 用例簡述011 安排時間和考場 教務人員安排考試時間和考試考場022 發布通知 教務人員發布考試通知033 發布成績 成績無誤後發布成績...