domain logic approaches

一、domain logic approaches

Transaction Script(事務腳本模式),是一種最簡單和最容易接受的處理業務的方法。這種模式是採用面向過程的方式來組織業務邏輯。一般狀況下，系統的一個流程會被實現爲一個方法，而後全部的方法被組織在一塊兒，放在一個類中。

設計思想：取數據-》邏輯-》數據展現。 存數據-》邏輯-》保存數據。

優勢

• 簡單，對大多數開發者均可用理解

• 一個事務的處理，不會影響到其餘的事務

  缺點

  業務邏輯複雜時，系統每增長一個業務流程，代碼就會增長一個或幾個方法，最後業務類中存在大量類似的代碼（重用性不強，難以維護）

  案例

  人事管理系統中的請假流程
• 判斷員工提交的數據是否合法
• 檢查提交請求的員工是否還有剩餘假期
• 批准假期，並記錄下來

 

二、domain model

　　若是說事務腳本是 面向過程 的，那麼領域模型就是 面向對象 的。面向對象的一個很重要的點就是：「把事情交給最適合的類去作」，即：「你得在一個個領域類之間跳轉，才能找出他們如何交互」，Martin Flower 說這是面向對象中最難的部分，這具備誤導的成份。確切地說，咱們做爲程序員若是已經掌握了 OOD 和 OOP 中技術手段，那麼如何尋找類之間的關係，可能就成了最難的部分。但在實際的狀況中，即使咱們不是程序員，也總能描述一件事情（即尋求關係），因此，找 對象之間的關係 還真的並非程序員最關係的部分，從技術層面來說，尋找類之間的關係由於與具體的編碼技巧無關，因此它如今對於程序員的咱們來講，應該是最簡單的部分，技術手段纔是這裏面的最難部分。

三、table module

　　表模塊（Table Module)，它是處理某一數據庫（其實只能是關係型數據庫）中表與視圖全部行的業務邏輯的一個實例。由於表模塊其實就一個數據集合（如：ado的RecordSet,ado.net的DataSet中的DataTable或類型化DataSet等之類），它能夠當作是一個數據容器，由於他用一個類(如Product)表示數據庫中對應表全部數據及行爲，咱們知道面向對象模型與關係模型存在差別，一般一個類與一個實體在概念上相對應，也就是一個類對應一個表，一個類的實例，即對象對應表中某一行記錄。類與表都是抽象的，集合的概念，像關係數據庫中表就一個二維（行、列）的集合，而表模塊用一個類直接表示表中全部數據及行爲，因此這個類能夠不須要實例化，它就至關於一個表(如.net 的DataTable)，這樣全部業務操做都直接用表模塊方式進行，從這一律念上來講，它也能夠當作是業務邏輯的一種實現方式，其實你們確定能夠得出，這種方式在本質上仍是採用事務腳本方式來實現業務邏輯，只是事務腳本方式，常常要求處理一個業務邏輯（如：查找指定ID的Product）就須要用SQL語句從數據庫中獲取數據，而這種方式先把數據庫的全部行加載到表模塊(如：DataTable)中，以後處理全部業務都直接與表模塊有關(如：查找指定ID的行，CRUD之類的操做),這正是表模塊與事務腳本的細微區別以後。