以asp.net為例，簡單三層就是 dal, bll,model 三層構成， dal層處理資料，負責與資料打交道，比如sql語句的書寫等,dal層處理完資料後的結果，交由bll層，bll層這時對資料進行邏輯整理。具體如下詳細說明：
現有乙個簡單的需求，乙個訂單裡可能包含幾個產品，這時，我們一般這樣處理，把訂單寫在主表，把具體的詳細商品寫在訂單詳細表，詳細表中有乙個主表的id,用於關聯二表。當使用者下單提交時，處理如下：
兩個表設為 主表orders, 副表 orderitem
dal層：寫sql語句，分別寫兩個方法，乙個是插入主表的方法，另乙個是插入副表的方法。
插入主表orders
public long add(modelorder model)
插入副表orderitem,語句這裡略掉，這裡只說明思路，不做真實的資料。
public long add(modelorderitem model)
這兩個方法，首先執行第乙個返回的id，然後第二個方法要用到這個返回的id,那麼這個邏輯處理就在bll層裡來處理了，這樣寫：
//插入主表後返回的id
long id = dal.add(model);
//如果執行成功，說明id>0
if(id>0)
這個方法執行完，再返回到頁面層級結果。
注意：其實上面的業務層處理嚴格的說寫的不正確，為什麼呢？設想我們插入主表成功了，但返回id後，插入副表的時候，出錯了，沒有插入，那麼就會造成資料庫裡只儲存了訂單資訊，但沒有訂單詳情資訊。如何解決呢？自然我們會想到了事務，一旦出現上述情況，使用事務時，資料庫會回滾，就是第二步出錯了，那麼第一步也會撤消。
using (sqltransaction transaction = connection.begintransaction()){}當然，這就個就要寫在dal層裡了，在dal層裡把各個的新增方法寫好了，然後在寫乙個方法，這個方法就是把各個方法加到事務中去，如果有一條語句執行時出錯，則事務回滾，等於沒有操作。
這基本上是乙個簡單三層的形象的最簡單的介紹，那麼簡單三層有時候不能滿足我們需要，比如說，你是一家軟體公司，那麼你開發了乙個軟體，用的sqlserver,而剛好碰到乙個客戶需要使用oracle，或是mysql,怎麼辦？當然，你也可以改，但是改的東西多了，最起碼整個資料層都要被你扒了一遍了，而有一種方法基本不用怎麼修改就可以達到需求，那就是工廠模式。
簡單介紹：使用工廠模式，面向介面的程式設計，把資料層和業務層使用介面來交接，面向介面，不面向具體的實現，只要操作介面，實現變了也無所謂。
首先我們還是定義sqlserverdal,bll,model三層，這次我們把dal與bll不直接進行互動了，中間插入乙個idal介面層，這個介面負責與bll通訊，
bll通過工廠反射等建立介面idal,
private readonly iorderaction dal = daorder.createorderaction();sqlserverdal只需實現idal即可，
public partial class orders:iorders如果某一天你想換資料庫，只需加相應的介面實現即可。
比如新增乙個oracelserverdal等
或是你提前把全部的資料層寫好sqlserverdal，oracelserverdal，mysqlserverdal……要哪個用哪個
當然，工廠模式帶來的好處也絕不僅僅是上述這點功勞。
三層架構與簡單工廠模式
3層即所謂 模式 檢視 控制器 檢視 view 代表使用者互動介面 模型 model 就是業務流程 狀態的處理以及業務規則的制定 控制 controller 可以理解為從使用者接收請求,將模型與檢視匹配在一起，共同完成使用者的請求 典型案例 基於反射工廠的三層架構 設計時一般所分模組 dal 資料庫...
三層，介面，簡單工廠，抽象工廠
我們做專案的時候通常用以下幾種架構 一.依賴三層進行開發 專案中有sqlserverdal，bll這倆個類庫，sqlserverdal有這樣乙個類customerdal.cs類，在bll層呼叫dal層如下 sqlserverdal.customerdal dal new sqlserverdal.c...
簡單工廠與三層架構（creator）
什麼是設計模式 設計模式是對特定場景下解決類和物件相互通訊的描述 乙個模式含有4個基本要素，名字，問題描述，解決方案和效果 design pattern 設計模式是一套被反覆使用，多數人知曉，設計經驗的總結 簡單工廠 負責根據我們傳入的引數來建立我們需要的物件,優點 體積小,只有乙個工廠類 缺點 不...