引言

　　Martin Fowler說過：“任何人都可以寫出計算機才能理解的代碼，只有寫出人能理解的代碼的程序員才是好程序員。”

每一個復(fù)雜的軟件都應(yīng)該按層來組織。每一層代表系統(tǒng)的一個邏輯部件。尤其是，業(yè)務(wù)層的模塊包括了所有使得系統(tǒng)運行的時候和其它層交互所需要的功能算法和計算，其他層包括數(shù)據(jù)訪問層DAL和表現(xiàn)層。

　　業(yè)務(wù)層是任何分層系統(tǒng)的神經(jīng)中心，包含了大部分的核心邏輯。因為這個原因，它也經(jīng)常被叫做：業(yè)務(wù)邏輯層BLL。

　　正文

　　1、業(yè)務(wù)邏輯層是什么

　　抽象的講，業(yè)務(wù)邏輯層是系統(tǒng)的一部分，用來處理和業(yè)務(wù)相關(guān)的任務(wù)。本質(zhì)上，業(yè)務(wù)邏輯層包括一系列執(zhí)行數(shù)據(jù)的操作。數(shù)據(jù)被模型化為問題域的實體，例如：發(fā)票、用戶、訂單、清單。另一方面，包括一些操作，例如：創(chuàng)建一個發(fā)票，添加一個用戶，處理一個訂單。

　　2、剖析業(yè)務(wù)層

　　如果你從縱向來看業(yè)務(wù)邏輯層，你會發(fā)現(xiàn)一些業(yè)務(wù)模型的實體，表達(dá)用戶策略和需求的業(yè)務(wù)規(guī)則，實現(xiàn)自動化功能的服務(wù)，定義文檔和數(shù)據(jù)從一層流轉(zhuǎn)到一層的工作流。

　　安全是一個在所有層都需要考慮的嚴(yán)重問題，但是在業(yè)務(wù)邏輯層，代碼扮演一個用戶界面層的守門人。在業(yè)務(wù)邏輯層的安全是以角色為基礎(chǔ)的，或者是限制對業(yè)務(wù)對象的訪問，只對授權(quán)用戶開放。

　　2.1領(lǐng)域?qū)ο竽Ｐ?/p>

　　領(lǐng)域?qū)ο竽Ｐ透鼉A向于對整個系統(tǒng)提供一個結(jié)構(gòu)化的視圖，包括實體的功能描述，實體間的關(guān)系，實體的職責(zé)。模型產(chǎn)生于用戶需求，使用UML的用例圖和類圖進(jìn)行文檔化。在模型中，你表示出用來存儲數(shù)據(jù)和暴露操作的真實世界元素。每一個實體代表模型中的一個角色，提供一些行為。每個實體都有自己的職責(zé)，依據(jù)領(lǐng)域的關(guān)系進(jìn)行交互。

　　很多應(yīng)用被打上復(fù)雜的標(biāo)記，實際上，如果你看到最終的技術(shù)實現(xiàn)，你會發(fā)現(xiàn)是相對簡單的。但是，整體來看這個應(yīng)用是復(fù)雜的，那是因為領(lǐng)域內(nèi)在的復(fù)雜性。通常來說，困難在于構(gòu)建一個適當(dāng)?shù)能浖Ｐ停皇亲罱K的實現(xiàn)。一個設(shè)計良好的模型，無論你運行到哪里，可以解決任何難度的復(fù)雜性。

　　對象模型和領(lǐng)域模型

　　為了清晰起見，讓我們確定一下“對象模型”和“領(lǐng)域模型”這兩個詞。盡管我們經(jīng)常會交替使用，實際上他們代表不同的事物，就算代表同一個事物的時候，他們的抽象級別也是不同的。我們所謂的“對象模型”就是簡單的對象圖。對于如何設(shè)計和實現(xiàn)模型沒有限制。如果你有了一些相互關(guān)聯(lián)的類，就有了一個對象模型。就像你看到的，描述相當(dāng)通用，適用于大部分的解決方案。

　　我們所謂的“領(lǐng)域模型”就是另外一回事了。領(lǐng)域模型是用來滿足一系列需求的對象模型。典型的，領(lǐng)域模型中的類沒有持久層的概念，是一種與其他幫助類庫中的類沒有關(guān)系的理想狀態(tài)。另外，領(lǐng)域模型設(shè)計用來解決特定的領(lǐng)域問題，試圖從實體和它們之間的關(guān)系來抽象業(yè)務(wù)流程和數(shù)據(jù)流。

　　記住領(lǐng)域模型也是一種特殊的設(shè)計模式，在后面我們會討論。

　　2.2 領(lǐng)域?qū)嶓w

　　從外部來看，業(yè)務(wù)邏輯層就是對業(yè)務(wù)對象的一系列操作。大多數(shù)情況，一個業(yè)務(wù)對象就是一個領(lǐng)域?qū)嶓w的實現(xiàn)，也就是一個封裝了數(shù)據(jù)和行為的類。也可能是一些實現(xiàn)特殊計算的輔助類。業(yè)務(wù)邏輯層決定業(yè)務(wù)對象之間如何交互。它也為參與交互的模塊、業(yè)務(wù)對象強加了一些規(guī)則和流程。

　　業(yè)務(wù)邏輯層處在一個分層系統(tǒng)的中間，和表現(xiàn)層、數(shù)據(jù)訪問層交換信息。業(yè)務(wù)邏輯層的輸入和輸出不是非要業(yè)務(wù)對象不可。在大多數(shù)情況，架構(gòu)師更傾向于在跨層之間使用DTO(Data Transfer Objects)進(jìn)行數(shù)據(jù)傳輸。

業(yè)務(wù)對象和數(shù)據(jù)傳輸對象有什么不同呢？

　　業(yè)務(wù)對象包含數(shù)據(jù)和行為，在業(yè)務(wù)邏輯中可以看做是充血的活動對象。數(shù)據(jù)傳輸對象只是一個值對象，是包含數(shù)據(jù)沒有附加的行為。處于序列化的目的，在業(yè)務(wù)對象中存儲的數(shù)據(jù)需要被序列化到數(shù)據(jù)傳輸對象中。數(shù)據(jù)傳輸對象除了setter和getter以外沒有邏輯行為。在模型中，每一個領(lǐng)域?qū)嶓w類可能會對應(yīng)多個數(shù)據(jù)傳輸對象。為什么是多個數(shù)據(jù)傳輸對象呢？

　　一個數(shù)據(jù)傳輸對象不是一個無行為的領(lǐng)域?qū)ο蟮暮唵胃北尽Ｏ喾矗粋€數(shù)據(jù)傳輸對象代表一個在特定上下文環(huán)境使用的領(lǐng)域?qū)ο蟮淖蛹＠纾涸谝粋€方法中，你需要一個只有Name和ID的CustomerDTO；其他地方你可能需要一個有Name、ID、Country、Contract的CustomerDTO。通常來說，一個領(lǐng)域?qū)ο笫且粋€包含很多對象的圖，例如：Customer包含orders，orderdetails，等等。

　　重點

　　關(guān)于DTO和OB的協(xié)同使用，可以引出一大串的、無意義的爭論。理論建議在任何情況下都是用DTO來減少層之間的耦合。實踐中，經(jīng)常會提醒我們已經(jīng)夠復(fù)雜的了，盡量避免不必要的附加?xùn)|西。作為一條實踐的準(zhǔn)則，我們建議在處理少于100個業(yè)務(wù)對象的模型的時候，你不需要這么做。在這些情況下，DTO和OB很可能很相似。

　　2.3 業(yè)務(wù)規(guī)則

　　在現(xiàn)實世界中的組織都是基于一系列的業(yè)務(wù)規(guī)則組成的。你可以爭論這些規(guī)則的級別，但是不可以否認(rèn)這些規(guī)則的存在。每一個組織都有追求的戰(zhàn)略，規(guī)則是實現(xiàn)戰(zhàn)略的主要規(guī)范。戰(zhàn)略指明了要達(dá)到的高度，規(guī)則明確了如何達(dá)到這個高度。

規(guī)范業(yè)務(wù)規(guī)則有各種方式。如果你生活和工作在一個完美的世界，每一個組織維護(hù)他自己的規(guī)則數(shù)據(jù)庫，這樣在一個項目中的各個團(tuán)隊中就很容易共享這些規(guī)則。大多數(shù)情況不是這樣的，搜集業(yè)務(wù)規(guī)格的過程開始于開發(fā)項目。結(jié)果就是，業(yè)務(wù)規(guī)則在項目快要結(jié)束的時候才整理出來，而且是在架構(gòu)師之間共享。

NET技術(shù)：.NET企業(yè)級架構(gòu)解決方案:業(yè)務(wù)層，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。