1

我們正在編寫一個MVC數據維護應用程序,它是大型項目的一部分。我們嘗試使用域驅動設計DDD。 關於此問題,已有其他問題,如here,herehere。 但他們並沒有完全回答我的問題。如何處理MVC ViewModel - 域模型 - MVC控制器和服務中的實體

由於數據庫有755個表,我們在數據層中也有有界的上下文。因此,我們爲商業,角色,產品,客戶等創建了有界的上下文。

我們遇到的問題是,在MVC應用程序中,我們有一個「初始設置」視圖,它使用ViewModel,最終跨越多個有界上下文(在實體框架6中使用IUnitOfWork模式)。 因此,該視圖必須寫入業務上下文和角色上下文。

該域模型將有一個Business模型和一個Address模型和一些更大的pbject圖中的其他模型。

視圖模型是這兩個和其他領域模型的扁平化,簡化模型:

public class InitialSetupViewModel 
{ 
    string BusinessName{get;set;} 
    string Street{get;set;} 
    string Street2{get;set;} 
    string State{get;set;} 
    string ZIP{get;set;} 
    ... 
} 

這個視圖模型應該映射到域模型,我們正在與Automapper做。

控制器獲得注入的域名服務:

public class SetupController : Controller 
{ 
    private readonly IMaintenanceService service; 

    public SetupController(IMaintenanceService maintenanceService = null) 
    { 
     service = maintenanceService; 
    } 

    public void Create(...????....) 
    { 
     service.CreateBusiness(..?.); 
    } 

} 

問題:

  1. 服務無法瞭解InitialSetupViewModel,所以什麼應該被傳遞到服務?

  2. 該服務必須知道有關BusinessDbContextRolesDbContext。所以我必須在兩者上調用SaveChanges(),這樣才能勝任一個IUnitOfWork的目的。 我是否還需要創建另一個包含業務和角色實體的UnitOfWork?

我不認爲這是合理的,以這兩個IUnitOfWorks合併成一個只是爲了讓這個MVC視圖的工作。但是,解決方案是什麼?

謝謝!

+2

您在控制器上的'Create'動作方法會接受您的視圖模型,然後您將轉換爲DTO並將其傳遞給您的服務 – 2014-12-01 21:22:41

+0

對於我來說,單個應用事務跨越多個有界上下文的事實表明設計異味。聚合之間有多種方式進行事後溝通,可能屬於不同的BC,但交易應儘可能多地修改一個聚合。 – guillaume31 2014-12-02 10:35:59

回答

1

它總是很難有你不知道的域強烈的意見,但這裏有雲:

  1. 如已經評論說,在Controller應承擔觀點和域之間的映射責任模型,DTO或你有什麼。可能需要輸入InitialSetupViewModel的實例,但實現細節可能會有所不同。

  2. 如果您發現自己需要打破有界上下文的邊界,那麼重塑域可能是是正確的選擇。儘管只關注工作單元模式,但我並不十分猶豫。

    單位工作實施的責任是跟蹤全部需要在一個事務中同步的域對象。在幾個不同的工作單元中涉及相同的域對象並沒有什麼奇怪的。這並不意味着當你處理另一種聚合時,你應該將「較小」的工作單元實現合併爲「較大」的實現,但在一個工作單元中同時包括「角色」和「業務」。

    這樣做應該而不是被你的視圖看起來像什麼,但是由你的域模型中的「真實」引誘,而不是僅僅處理域對象的集合,你的域可能應該描述合適的聚集體。

也許它甚至OK保存有獨立的交易每個域對象(工作單位),即如果他們同步是沒有必要的 - 例如,如果(或者甚至是期望的)沒有堅持下去,Business不會阻止Roles通過,反之亦然。實際上,我認爲人們甚至可以爭辯說,如果有界的上下文實際上是正確定義的,那麼應該是

我希望這些評論有所幫助。

Martin Fowler on Unit of Work and Aggregates

相關問題