1

在我們以前的應用程序中,我們使用了StructureMap,我們可以編寫很少的代碼。asp.net核心內建依賴注入長代碼

每次服務前,我們添加了依賴關係,如:

[SetterProperty] 
public IXService XService { get; set; } 

,並在構造函數中

ObjectFactory.BuildUp(this); 

然後在測試中,我們可以簡單地通過

var service = new XService(); 

實例它現在,我們啓動另一個應用程序並使用asp.net核心內置DI容器。 它看起來像我們應該寫很多代碼,而且很長的構造爲每個測試:

private readonly ILogger<AccountsController> _logger; 
    private readonly IMapper _mapper; 
    private readonly IAccountBlService _accountBlService; 
    private readonly IValidationHelper _validationHelper; 
    private readonly IValidator<AccountDTO> _accountDTOValidator; 
    private readonly Example _example; 
    private readonly IConfiguration _configuration; 

    public AccountsController(BillingContext context, ILogger<AccountsController> logger, IMapper mapper, IAccountBlService accountBlService, 
     IValidationHelper validationHelper, IValidator<AccountDTO> accountDTOValidator, IOptions<Example> example, IConfiguration configuration) 
    { 
     _logger = logger; 
     _mapper = mapper; 
     _accountBlService = accountBlService; 
     _validationHelper = validationHelper; 
     _accountDTOValidator = accountDTOValidator; 
     _configuration = configuration; 
     _example = example.Value; 
    } 

有我們沒有找到一個較短的方法嗎?計劃在不久的將來?我們應該使用StructureMap來代替內置的容器嗎?或者這有什麼缺點?謝謝!

回答

5
  • 有沒有更短的方式,我們沒有找到? 總之:沒有,沒有默認容器。但是我建議你閱讀Mark Seemann在.NET中的依賴注入(如果你有,那麼請忽略我這麼說),因爲你聽說過「Composition Root」嗎?恕我直言,你聲明依賴的方式有相同數量的代碼,只是分散在你的代碼庫中。雖然你應該把它放在一個可維護性的地方。
  • 是一個計劃在不久的將來?不是我所知道的,但真的如果你看看它,它是相同數量的代碼,只是集中。然而,我們使用NServiceBus的能力來調用BusConfiguration上的「RegisterComponents」,它使用反射來在一次調用中註冊所有的依賴關係。你可以尋找可以做同樣的容器。現在,如果你考慮你的測試,如果你使用XUnit,你可以通過de test類的構造函數來設置你的SUT。在工廠類重構它,所以你只需要寫一次。通過這種方式,您還可以將模擬測試保持乾淨。
  • 我們應該用StructureMap,而不是內置容器? 如果你願意。我們使用Autofac。
  • 還是有這個缺點? 不是我們迄今爲止遇到的。有時你需要IServiceProvider來獲得特殊的「技巧」,但總有一種方法。

注:如果您擔心在你的控制器7只依賴(這是很多確實)有幾個選項:

  • 看那依賴的範圍。如果它在1種或2的操作方法僅用於你也可以把它聲明[FromService]在操作方法的簽名

  • 是您的控制器做得太多?小心上帝的課程。也許它需要重構。畢竟,控制器不過是動作方法的邏輯集合。

  • 可以依賴結合?有時似乎他們需要分離,但在大多數情況下,他們總是成對的。看起來有很高的凝聚力,你可以把它們組合成一個輔助班,以保持凝聚力。