訪問存儲庫中的UnitOfWork是不是很糟糕的設計？

背景：實體框架4.1和MVC4訪問存儲庫中的UnitOfWork是不是很糟糕的設計？

我的設置有模型實體，然後是一個通用的存儲庫，然後建立特定的存儲庫，如UserRepository，從通用存儲庫繼承的ProductRepository。

然後我有一個服務層使用這些存儲庫以及任何業務邏輯，並且可以在這裏訪問UnitOfWork對象來調用Commit。

隨着工作模式的單位，我的quesiton是：

它是設計不良，讓庫層可以訪問的UnitOfWork對象？

對我來說，這似乎是一個'泄漏'，因爲現在事情可能會提交時，你甚至沒有意識到它。

這是正確的嗎？

例如

public class ProductService 
{ 


    public void SaveProduct(Product product) 
    { 
     try 
     { 
     productRepository.Save(product); 
     statsRepository.Update(product); 
     this.UnitOfWork.Commit(); 
     } catch(..) 
     { 
      // 
     } 
     finally() 
     { 
     // 
     } 


    } 

}

現在，如果其中任何一個調用失敗，提交將不會被調用。

但是，如果在abcRepository層中有權訪問UofW對象並調用commit，則它的行爲將以不一致的方式進行。

來源

2013-05-02 loyalflow

在我看來，創造單位成爲承諾者應該是責任。該存儲庫可能不具有該特定工作單元的整個上下文。 – Matthew 2013-05-02 18:50:59

我之前見過'UnitOfWork'的方式是'UnitOfWork'，而不是另一種方式訪問版本庫。 – Charles380 2013-05-02 18:59:06

@Mthethew，以便我的情況在MVC控制器中，然後傳遞給ABCService類。 – loyalflow 2013-05-02 19:05:51

我認爲這是實現倉庫的正確方法和的UnitOfWork

http://code.cmsstores.com/implementing-unit-of-work-pattern-dot-net/

來源

2013-05-02 18:58:53

我認爲倉庫不應該訪問的U-O-W，如馬修已經評論。你的問題幾乎回答自己。

Re：現在，如果其中任何一個調用失敗，提交將不會被調用。 -

這通常很好，對不對？你不想部分地提交你的修改。

來源

2013-06-26 02:26:48 mayu

訪問存儲庫中的UnitOfWork是不是很糟糕的設計？

回答

相關問題