基礎(chǔ)才是重中之重~Data層如何調(diào)用BLL層的方法,如果覺(jué)得奇怪請(qǐng)看本文章

回到目錄

看似不倫不類

這個(gè)題目有點(diǎn)不倫不類,或者說(shuō)有點(diǎn)偽模式了,不錯(cuò),確實(shí)是這樣,我們正確的開發(fā)思維是WEB層->BLL層->DATA層,每個(gè)層有對(duì)它下層的引用,下層不能引用上層,因?yàn)檫@會(huì)出現(xiàn)相互引用的錯(cuò)誤,在實(shí)際工作中,BLL層會(huì)有涉及到各個(gè)業(yè)務(wù)的代碼組織,實(shí)現(xiàn)數(shù)據(jù)持久化一般在Data層完成,這是可以理解的,也是我們經(jīng)常使用的開發(fā)模式,這當(dāng)然不是今天的重點(diǎn),今天主要說(shuō)一個(gè)實(shí)際問(wèn)題,如訂單處理的場(chǎng)合.

一般訂單處理流程如下:

1 用戶選擇商品到購(gòu)物車

2 用戶確定購(gòu)買,生成訂單

3 選擇一種或者幾種支付方式

4 支付完成,回寫訂單,修改訂單狀態(tài)

5 支付交易成功,或者失敗

OK,這種訂單業(yè)務(wù)事實(shí)上是很復(fù)雜了,它會(huì)涉及到很多表的操作,它可能由多個(gè)開發(fā)人員去編寫,最后進(jìn)行統(tǒng)一組合,而為了保證數(shù)據(jù)的有效性,我們會(huì)把代碼重裝到事務(wù)里,這時(shí)問(wèn)題就來(lái)了

當(dāng)你的訂單主方法在data層實(shí)現(xiàn),如何去調(diào)用bll已經(jīng)寫好的方法呢?我們總不能再重新寫一個(gè)吧,當(dāng)然不能,相同的代碼不能出現(xiàn)兩次,這是我們的原則,呵呵.

方法回調(diào)

概念:我們?cè)谝粋€(gè)方法里處理事件,事件處理完成后,再調(diào)用原方法層次的某個(gè)方法,這種調(diào)用,我們可以稱為回調(diào)方法,它可以通過(guò)委托來(lái)實(shí)現(xiàn),而對(duì)于如今的業(yè)務(wù),我們也可以通過(guò)這種方式來(lái)實(shí)現(xiàn),看一下DEMO

這是我們的data層方法簽名:

public void GeneratorOrder(List<Order_Info> list, Action<IUnitOfWork, int, int> authorizeClassroom)

我們看到,它的參數(shù)里有個(gè)Action委托,它有三個(gè)參數(shù),這個(gè)方法是通過(guò)BLL層傳遞進(jìn)來(lái)的,當(dāng)data層的工作完成后,可以回調(diào)這個(gè)BLL的方法,我們看一下BLL層這個(gè)方法的簽名:

  void AuthorizeClassroom(IUnitOfWork db, int userID, int classroomID)

看一下,BLL層去調(diào)用data層方法,將把委托實(shí)例以參數(shù)的形式傳入data層

orderInfoRepository.GeneratorOrder(list, AuthorizeClassroom);

最后,使用我們的事務(wù),把它們組合到一起(BLL層與Data層使用同一個(gè)事務(wù),注意,它不是分布式事務(wù),前提是它們的數(shù)據(jù)上下文是一個(gè))

   TransactionScopeNoMsdtc.UsingNoMsdtc(Db, true, () =>
          {
             ...
          }

最后,通過(guò)SQL監(jiān)視工作看到的結(jié)果就是它們處在同一事務(wù)塊里,呵呵.

回到目錄