胖域模型=>低效？

在DDD中，我們將數據庫抽象成我們操作的各種模型，並將其視爲模型所在的存儲庫。然後，我們在其上添加數據層和服務/業務層。我的問題是，這樣做是否會通過構建胖模型來創建數據傳輸效率低下的問題？胖域模型=>低效？

例如，假設我們的系統在屏幕上顯示客戶的發票。在OOP方面的它思考，我們就可能結束了一個對象，它看起來有點像這樣：

class Invoice { 
    Customer _customer; 
    OrderItems _orderitems; 
    ShippingInfo _shippingInfo; 
} 

class Customer { 
    string name; 
    int customerID; 
    Address customerAddress; 
    AccountingInfo accountingInfo; 
    ShoppingHistory customerHistory; 
} 
    (for the sake of the question/argument, 
    let's say it was determined that the customer class had to 
    implement AccountingInfo and ShoppingHistory)

如果發票僅需要打印的客戶名稱，我們爲什麼會隨身攜帶所有其他行李呢？使用存儲庫類型的方法好像我們將構建這些需要所有這些資源（CPU，內存，複雜查詢連接等）的複雜域對象，然後通過管道將其傳輸到客戶端。

只需將customerName屬性添加到發票類中就可以脫離抽象，看起來像是一種可怕的做法。另一方面，填充像Customer這樣的對象的一半似乎是一個非常糟糕的主意，因爲您最終可能會創建同一對象的多個版本（例如，有一個Address，但沒有ShoppingHistory，而有一個擁有AccountingInfo但沒有地址等等）。我錯過了什麼，或者沒有理解？

來源

2009-07-18 MunkiPhD

由於良好的對象關係映射器可以延遲加載關係，因此您會爲客戶退回發票，但忽略其會計和購物歷史記錄。如果你沒有使用oject-relational映射器，你可以推出自己的產品。

通常，您不能在客戶端執行此操作，因爲您已經跨越了交易邊界（結束了您的數據庫交易），因此它取決於您的服務層以確保正確的數據已加載。

測試正確的數據是可用的（而不是太多）通常在服務層的單元測試中是很好的。

來源

2009-07-18 18:27:13 RichH

好點。我想我一定還沒有完全理解延遲加載>。< – MunkiPhD 2009-07-18 20:10:13

您說「確定客戶類必須實施AccountingInfo和ShoppingHistory」，因此清楚地顯示發票並不是系統執行的唯一任務（它還「確定」客戶還需要其他功能除此以外？-）。

因此，無論如何您需要客戶表（對於其他功能） - 當然，您的發票打印機需要從該表中獲取客戶數據（即使只是名稱），這與其他功能所使用的相同在系統中。

因此，「開銷」純粹是虛幻的 - 當您單獨看待某個功能時，它似乎就存在，但當您將整個系統視爲一個整體時，根本不存在。

來源

2009-07-18 18:14:25

胖域模型=>低效？

回答

相關問題