當解決方案的規模和范圍擴大時，保持整體應用程序的靈活性變得更加困難。 對象之間的依賴關系不斷增長，更改一個類可能需要更新其他類，依賴注入 (DI) 可以幫助解決這一挑戰。

如您所知，依賴注入是“控制反轉”（IoC）編程原理的一種形式。 這意味著類不會創建它們所依賴的對象，DI 框架具有負責揭示和解決依賴關系的容器。

DevExpress WPF v21.2正式版下載

依賴注入可以解決哪些問題？

假設您有一個使用數據服務獲取數據的視圖模型：

public class UserViewModel
{
MyDataService dataService;
public UserViewModel() {
this.dataService = new MyDataService();
}
}

視圖模型依賴于一個服務——這意味著 MyDataService 是 UserViewModel 的依賴，直接在視圖模型類中創建服務非常容易，但是這種方法有幾個缺點：

• 類緊密相連，每次使用 UserViewModel 時，它都會隱式創建 MyDataService 的一個實例。
• 如果以后修改 MyDataService 的初始化方式，則必須修改 MyDataService 初始化的所有視圖模型。
• 您不能專門為 UserViewModel 類創建單元測試，因為它依賴于 MyDataService。 如果測試失敗，您可能無法確定錯誤是在 UserViewModel 中還是在 MyDataService 中。

如果將 MyDataService 傳遞給 UserViewModel 的構造函數，則可以避免這些問題：

public class UserViewModel
{
MyDataService dataService;
public UserViewModel(MyDataService dataService) {
this.dataService = dataService;
}
}

不幸的是，這種技術也有缺陷：

• 在每個類中創建不同的視圖模型，并且它們都必須知道如何創建 MyDataService。
• 如果不創建靜態屬性，可能很難在多個視圖模型之間共享同一個 MyDataService 實例。

依賴注入的主要思想是集中解決所有依賴，這意味著您的程序中有一個單獨的塊來初始化新的類實例并將參數傳遞給它們。 盡管您可以為此實現自己的邏輯，但使用 DI 框架來幫助避免/消除示例代碼會更方便。

依賴注入模式具有以下優點：

• 類之間是松散耦合的，因此您可以輕松地修改依賴項，例如，將MyDataService替換為MyDataServiceEx。
• 創建單元測試很容易，因為您可以將模擬參數傳遞給測試的類。
• 您的項目結構良好，因為始終知道所有依賴項的管理位置。

將依賴注入應用到WPF應用程序

.NET 社區有許多很棒的框架來幫助您在應用程序中實現依賴注入模式，所有這些框架都有兩個主要特點：

• 您可以在容器中注冊類。
• 您可以創建具有已初始化依賴項的對象。

容器是 DI 框架中的中心對象，可以自動檢測和解決類依賴關系。 某些框架可以將參數注入類屬性，但最常見的方法是將參數注入構造函數。

讓我們修改 MainViewModel 構造函數，使其接受接口替代類：

public class MainViewModel
{
IDataService dataService;
public MainViewModel(IDataService dataService) {
this.dataService = dataService;
}
}

這將允許您在將來使用不同的 IDataService 實現。

進行此更改后，我們需要創建一個 DI 容器來注冊 MyDataService 并實例化 MainViewModel：

protected override void OnStartup(StartupEventArgs e) {
base.OnStartup(e);
var builder = new ContainerBuilder();
//allow the Autofac container resolve unknown types
builder.RegisterSource(new AnyConcreteTypeNotAlreadyRegisteredSource());
//register the MyDataService class as the IDataService interface in the DI container
builder.RegisterType<MyDataService>().As<IDataService>().SingleInstance();
IContainer container = builder.Build();
//get a MainViewModel instance
MainViewModel mainViewModel = container.Resolve<MainViewModel>();
}

在此示例中，我們使用了 Autofac 框架，但您可以使用任何其他 DI 框架，例如 Unity 或 Ninject。 DI 容器創建 MainViewModel 并自動將 MyDataService 注入 MainViewModel 構造函數，這允許您在每次創建具有 IDataService 參數類型的類時避免 MyDataService 初始化。

然后我們需要將 MainViewModel 連接到它的視圖：MainView，最明顯的策略是在視圖構造函數中設置 DataContext：

public MainView() {
InitializeComponent();
this.DataContext = container.Resolve<MainViewModel>();
}

但是，要訪問 DI 容器，您必須將其設為靜態或將其傳遞給每個視圖構造函數。 一個更好的解決方案是創建一個標記擴展，它根據其類型返回一個視圖模型實例：

public class DISource : MarkupExtension
{
public static Func<Type, object> Resolver { get; set; }
public Type Type { get; set; }
public override object ProvideValue(IServiceProvider serviceProvider) => Resolver?.Invoke(Type);
}

<UserControl DataContext="{local:DISource Type=local:MainViewModel}">

最初，標記擴展未綁定到任何 DI 容器。 要允許擴展使用您的容器，請按以下方式指定視圖模型解析器：

public partial class App : Application
{
protected override void OnStartup(StartupEventArgs e) {
base.OnStartup(e);
//...

IContainer container = builder.Build();
DISource.Resolver = (type) => {
return container.Resolve(type);
};
}
}

這種技術允許 DISource 與任何可能的容器一起工作。

依賴注入和DevExpress服務

在上面的示例中，我們使用了不與可視控件通信的抽象數據服務。 如您所知，許多DevExpress WPF服務使用視圖控件，因此服務必須知道使用哪個控件。 例如，如果您希望將 NavigationFrameService 注入到視圖模型中，還需要將此服務附加到相應的 NavigationFrame 控件。

在視圖模型中創建一個包含服務的公共屬性，并將服務綁定到 NavigationFrame：

public class MainViewModel {
public INavigationService NavigationService { get; }

public MainViewModel(INavigationService navigationService) =>
NavigationService = navigationService;
}

<dxwui:NavigationFrame>
<dxmvvm:Interaction.Behaviors>
<common:AttachServiceBehavior Service="{Binding NavigationService}"/>
</dxmvvm:Interaction.Behaviors>
</dxwui:NavigationFrame>

AttachServiceBehavior 是一個簡單的附加操作，它在服務屬性更改時調用 NavigationFrameService.Attach。 雖然 AttachServiceBehavior 不包含在我們的庫中，但您可以在此處獲取其代碼：。即使 MainViewModel 使用 NavigationFrameService，它也不必實現 ISupportServices 接口。 此外，導航中涉及的所有子視圖都可以在不附加到 NavigationFrame 的情況下使用該服務——因為它已經在主視圖級別進行了配置。

并非所有DevExpress 服務都需要可視化組件，某些服務，例如 或 ，不需要顯式附加，因此您可以將它們作為任何其他非 DevExpress 服務注入。

 在某些情況下，如果需要為特定視圖配置服務，則使用 DI 容器注入服務可能并不明智。 例如，如果您有一個綁定到視圖模型命令的服務，就會出現這種情況，直接在視圖中定義服務并在那里配置所有綁定要容易得多。

DevExpress WPF | 下載試用

DevExpress WPF擁有120+個控件和庫，將幫助您交付滿足甚至超出企業需求的高性能業務應用程序。通過DevExpress WPF能創建有著強大互動功能的XAML基礎應用程序，這些應用程序專注于當代客戶的需求和構建未來新一代支持觸摸的解決方案。 無論是Office辦公軟件的衍伸產品，還是以數據為中心的商業智能產品，都能通過DevExpress WPF控件來實現。

DevExpress技術交流群6：600715373      歡迎一起進群討論