面象對象開發項目三層架構
面象對象開發項目三層架構：
- 界面層
- 業務邏輯層
- 資料通路層 （分為實體類和資料通路類）
一、實體類
- 資料庫中的表映射為一個類，類名與表名一緻。表中的每一列，都為該類下的成員變量和屬性也就是最簡單的封裝。
- 把資料庫中的表名變為類的類名
- 把資料庫中的每一列，變為實體類中的成員變量和屬性（也就是隊每個資料庫中的字段封裝）
- 列明與屬性名一緻。成員變量名 : 在列明前邊加上下劃線，因為在外部通路隻能通路到屬性。
二、資料通路類
- 将某個表的資料庫操作協程一個方法，放到該類中，供外部調用。
題外話 ： 可通路性
| public | 通路不受限制 |
|---|---|
| protected | 通路僅限于此類和從此類派生的類 |
| private | 通路僅限于此類 |
C# 三層架構詳解
這裡引用一下大佬的 "豬仔的一生"圖解，能讓大家更好的了解三層的思想。
引言
通常意義上的三層架構是将真個業務應用劃分為：界面層（UI層）、業務邏輯層（B層）、資料通路層（D層）。對于複雜的系統分層讓結構清晰，便于開發人員對系統進行整體的了解、把握；而且便于維護，系統基本的架構可以通過工具自動生成代碼。當資料庫發生改變時，隻用重新生成代碼，改動業務邏輯層的部分代碼即可。
對比以上兩張圖檔，我們可以看出：
（1）資料庫好比豬圈，所有的豬都有序地按區域或編号，存放在不同的豬欄裡
（2）DAL好比是屠宰場 ，把豬從豬圈取出來進行（處理）屠殺，按要求取出相應的部位（字段），
或者進行歸類整理（統計），形成整箱的豬肉（資料集），傳送給食品加工廠（ BLL ）。本來這裡都是
同一夥人既管抓豬，又管殺豬的，後來覺得效率太低了，就讓一部分人出來專管抓豬了（ DBUtility ），
根據要求來抓取指定的豬
（3）BLL 好比食品加工廠 ，将豬肉深加工成各種可以食用的食品（業務處理）
（4）UI 好比商場 ，将食品包裝成漂亮的可以銷售的産品，展現給顧客（ UI 表現層）
（5）豬肉好比 Model ，無論是哪個廠（層），各個環節傳遞的本質都是豬肉，豬肉貫穿整個過程
（6）通用類庫 Common 相當于勞工使用的各種工具，為各個廠（層）提供諸如殺豬刀、繩子、
剪刀、包裝箱、工具車等共用的常用工具（類）。其實，每個部門本來是可以自己制作自己的工
具的，但是那樣會使效率比較低，而且也不專業，并且很多工作都會是重複的。是以，就專門有
人開了這樣的工廠來制作這些工具，提供給各個工廠，有了這樣的分工，工廠就可以專心做自己的事情了
資料通路層
- 一般隻編寫基本的增删改查方法，不能出現業務邏輯代碼
- 作用有倆點：第一 解析對象–組合SQL 第二 封裝對象–向上傳（也就是BLL–業務邏輯層）
業務邏輯層
- 一般隻編寫業務邏輯代碼，根據使用者的需求決定如何如何調用資料通路層的方法，不能出現任何的SQL語句即資料通路代碼
- 隻能調用DAL（資料通路層）中的方法，不能調用其他任何層的方法
- 作用一：處理業務邏輯 作用二： 傳遞資料
使用者界面層（UI層）
- 一般隻編寫擷取使用者操作資訊、數驗證、資料展示代碼
- 隻能調用BLL(業務邏輯層)的方法，不能調用DAL中的方法
- 作用一：封裝對象–向下傳（也就是BLL–業務邏輯層） 作用二： 解析對象–展示資料