2014-01-21 32 views
0

我試圖讓團結依賴注入與利用實體框架WCF服務工作,但我越來越感到困惑的使用情境和存儲庫的。使用依賴注入WCF服務方法和EF

我設計它的方式是擁有一些存儲庫類,例如UserRepository,MessageRepository,LocationRepository,每個存儲庫接受一個EF DbContext對象作爲構造參數。這使我可以通過調用context.Save()或回滾等來控制上下文級別的工作單元來控制跨存儲庫的事務。

我在混亂的是,我不知道如何在依賴注入表示此。我想要兩個場景

a)當WCF服務通過WCF方法實例化時,我希望它使用我創建的DbContext類並創建存儲庫對象,傳遞創建的DbContext,它將連接到實體框架數據庫。

B)當WCF服務的方法是從一個單獨的測試項目進行測試,我想嘲笑資源庫對象返回嘲笑數據。

如果我只是使用存儲庫類,這將是相對簡單的,因爲在我可以調用Container.Resolve()的每個WCF服務方法中,然後我可以使用Unity WCF工廠來設置WCF實例的具體類型,在我的測試項目中爲模擬類型手動配置Unity容器。

但是,難點在於我的存儲庫需要一個DbContext類作爲構造函數參數傳遞,這個構造函數參數將在存儲庫的生命週期中生存,並且我還需要能夠在我的服務中引用它方法,例如

public bool CreateUser(DbUser user) 
{ 
    try 
    { 
     using (var context = new MyDbContext()) 
     { 
      var repository = new UserDataRepository(context); 

      user.GenerateUserLight(); 
      user.GenerateUserProfileLight(); 

      var result = repository.InsertItem(user); 
      repository.Save(); 

      return result; 
     } 
    } 
    catch (Exception ex) 
    { 
     return false; 
    } 
} 

我怎麼能適應使用統一依賴注入,所以我可以嘲笑它的測試項目上面的方法?

回答

0

至於我可以看到這裏的問題是,你應該你的倉庫內創建背景,但事實上,你實際上是newing了在服務範圍內,然後將其傳遞到你的倉庫是一個有點代碼味道。

爲什麼不讓倉庫處理DbContext?這樣,您就不會將存儲庫首先與Entity Framework耦合。

服務只能有一個IUserRepository接口..沒有具體實施的依賴關係。

private readonly IUserRepository _userRepository; 

public MyService(IUserRepository userRepository) 
{ 
    this._userRepository = userRepository; 
} 
public bool CreateUser(DbUser user) 
{ 
    try 
    { 
      user.GenerateUserLight(); 
      user.GenerateUserProfileLight(); 

      var result = this._userRepository.InsertItem(user); 
      this._userRepository.Save(); 

      return result; 
    } 
    catch (Exception ex) 
    { 
     return false; 
    } 
} 

用戶存儲庫將在其構造函數接受的DbContext,你需要註冊與DI容器也是上下文,這樣,當它注入到該服務的DI可以構造UserRepository。

public class UserRepository : IUserRepository 
{ 
    private readonly MyDbContext context; 

    public UserRepository(MyDbContext context) 
    { 
     this.context = context; 
    } 
} 

然後,您可以簡單地通過構造函數將「UserRepository」注入服務。

這也使您能夠創建不需要背景可言,只要爲您的存儲庫的接口模擬類型的數據倉庫。