用微軟.NET架構企業解決方案 學習筆記（四）業務層

 

業務層

 

 

引言

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

　　   每一個複雜的軟體都應該按層來組織。每一層代表系統的一個邏輯組件。尤其是，業務層的模組包括了所有使得系統啟動並執行時候和其它層互動所需要的功能演算法和計算，其他層包括資料訪問層DAL和表現層。

　　業務層是任何分層系統的神經中心，包含了大部分的核心邏輯。因為這個原因，它也經常被叫做：商務邏輯層BLL。

本文

      1、商務邏輯層是什麼

      抽象的講，商務邏輯層是系統的一部分，用來處理和業務相關的任務。本質上，商務邏輯層包括一系列執行資料的操作。資料被模型化為問題域的實體，例如：發票、使用者、訂單、清單。另一方面，包括一些操作，例如：建立一個發票，添加一個使用者，處理一個訂單。

      2、剖析業務層

      如果你從縱向來看商務邏輯層，你會發現一些業務模型的實體，表達使用者策略和需求的商務規則，實現自動化功能的服務，定義文檔和資料從一層流轉到一層的工作流程。

      安全是一個在所有層都需要考慮的嚴重問題，但是在商務邏輯層，代碼扮演一個使用者介面層的守門人。在商務邏輯層的安全是以角色為基礎的，或者是限制對業務對象的訪問，只對授權使用者開放。

      2.1、領域物件模型

      領域物件模型更傾向於對整個系統提供一個結構化的視圖，包括實體的功能描述，實體間的關係，實體的職責。模型產生於使用者需求，使用UML的使用案例圖和類圖進行文檔化。在模型中，你表示出用來儲存資料和暴露操作的真實世界元素。每一個實體代表模型中的一個角色，提供一些行為。每個實體都有自己的職責，依據領域的關係進行互動。

      很多應用被打上複雜的標記，實際上，如果你看到最終的技術實現，你會發現是相對簡單的。但是，整體來看這個應用是複雜的，那是因為領域內在的複雜性。通常來說，困難在於構建一個適當的軟體模型，而不是最終的實現。一個設計良好的模型，無論你運行到哪裡，可以解決任何難度的複雜性。

　　

      物件模型和領域模型

      為了清晰起見，讓我們確定一下“物件模型”和“領域模型”這兩個詞。儘管我們經常會交替使用，實際上他們代表不同的事物，就算代表同一個事物的時候，他們的抽象層級也是不同的。我們所謂的“物件模型”就是簡單的對象圖。對於如何設計和實現模型沒有限制。如果你有了一些相互關聯的類，就有了一個物件模型。就像你看到的，描述相當通用，適用於大部分的解決方案。

      我們所謂的“領域模型”就是另外一回事了。領域模型是用來滿足一系列需求的物件模型。典型的，領域模型中的類沒有持久層的概念，是一種與其他協助類庫中的類沒有關係的理想狀態。另外，領域模型設計用來解決特定的領域問題，試圖從實體和它們之間的關係來抽象商務程序和資料流。

      記住領域模型也是一種特殊的設計模式，在後面我們會討論。

      2.2 領域實體

      從外部來看，商務邏輯層就是對業務對象的一系列操作。大多數情況，一個業務對象就是一個領域實體的實現，也就是一個封裝了資料和行為的類。也可能是一些實現特殊計算的輔助類。商務邏輯層決定業務對象之間如何互動。它也為參與互動的模組、業務對象強加了一些規則和流程。

      商務邏輯層處在一個分層系統的中間，和表現層、資料訪問層交換資訊。商務邏輯層的輸入和輸出不是非要業務對象不可。在大多數情況，架構師更傾向於在跨層之間使用DTO(Data Transfer Objects)進行資料轉送。

      業務對象和資料轉送對象有什麼不同呢？

      業務對象包含資料和行為，在商務邏輯中可以看做是充血的使用中的物件。資料轉送對象只是一個值對象，是包含資料沒有附加的行為。處於序列化的目的，在業務對象中儲存的資料需要被序列化到資料轉送對象中。資料轉送對象除了setter和getter以外沒有邏輯行為。在模型中，每一個領域實體類可能會對應多個資料轉送對象。為什麼是多個資料轉送對象呢？

      一個資料轉送對象不是一個無行為的領域對象的簡單副本。相反，一個資料轉送對象代表一個在特定上下文環境使用的領域對象的子集。例如：在一個方法中，你需要一個只有Name和ID的CustomerDTO；其他地方你可能需要一個有Name、ID、Country、Contract的CustomerDTO。通常來說，一個領域對象是一個包含很多個物件的圖，例如：Customer包含orders，orderdetails，等等。

 

      重點

      關於DTO和OB的協同使用，可以引出一大串的、無意義的爭論。理論建議在任何情況下都是用DTO來減少層之間的耦合。實踐中，經常會提醒我們已經夠複雜的了，盡量避免不必要的附加東西。作為一條實踐的準則，我們建議在處理少於100個業務對象的模型的時候，你不需要這麼做。在這些情況下，DTO和OB很可能很相似。

      2.3 商務規則

      在現實世界中的組織都是基於一系列的商務規則組成的。你可以爭論這些規則的層級，但是不可以否認這些規則的存在。每一個組織都有追求的戰略，規則是實現戰略的主要規範。戰略指明了要達到的高度，規則明確了如何達到這個高度。

      規範商務規則有各種方式。如果你生活和工作在一個完美的世界，每一個組織維護他自己的規則資料庫，這樣在一個項目中的各個團隊中就很容易共用這些規則。大多數情況不是這樣的，搜集業務規格的過程開始於開發項目。結果就是，商務規則在項目快要結束的時候才整理出來，而且是在架構師之間共用。

      依賴於進行操作的上下文環境，商務規則不是固定的，是變化的。這就意味著在商務邏輯層中，應該以一種靈活的方式實現規則，最好是通過規則引擎實現。在最進階別的抽象中，規則引擎是軟體的一部分，以某種規範引入規則，並且應用於業務對象。

      在實際中，商務規則通常就是一系列的if。。。else。。。語句，映射為業務對象的操作，也就是所謂的商務邏輯。

　　在實際的系統中，一個的業務對象可能會映射出上千條規則。你的規則引擎應該足夠靈活，以適應可能的變化以及修複一些誤解。

      2.4 驗證

      業務對象的屬性來自於實體的屬性。業務對象的方法來自於自己的一系列職責。

 

      來源：http://www.cnblogs.com/virusswb/archive/2010/08/20/architecture-microsoft-net-solution-4.html