1 回答

TA貢獻1839條經驗 獲得超15個贊
通常,當我讀到 DI 時,它被視為全部和全部。即使在我的小而簡單的項目中,我也經常大量使用 IoC,但是,它只是一種模式,并且和其他所有東西一樣都有一席之地。
Microsoft Press 的Adaptive Code via C#書很好地解釋了 SOLID,證明了其使用的合理性,涵蓋了 DI 的各種形式以及每種技術的成本/收益。對我來說,它對這些問題、管理項目增長和處理外部依賴關系有很大的意義。
除了抽象和分解引導/模塊化過程的系統之外,我不會將其傳遞UnityContainer給我的引導程序之外的任何東西。除了您對此提出的觀點之外,Unity 是您的應用程序的第三方依賴項,就像其他任何東西一樣,我會非常有選擇地選擇我將自己綁定到哪個(如果有的話)。
對于上面的示例,我將使用一個簡單的工廠。您可以隨意抽象它,但一個好的折衷方案是減輕您的主要 ViewModel 必須創建自己的孩子的負擔。
使用 DI 時,在適當的地方自己實例化事物并沒有錯。最合適的地方當然是工廠。正如您所說,我不會創建通用工廠,這基本上就像傳遞 IoC 容器一樣。而是定義一個類型化工廠:
public interface IWorkspaceItemViewModelFactory
{
WorkspaceItemViewModel CreateWorkspaceItem();
}
這個的實現可能看起來像這樣:
public class WorkspaceItemViewModelFactory
{
private readonly IWorkspaceManager _workspaceManager;
public WorkspaceItemViewModelFactory(IWorkspaceManager workspaceManager)
{
_workspaceManager = workspaceManager;
}
public WorkspaceItemViewModel CreateWorkspaceItem()
{
return new WorkspaceItemViewModel(_workspaceManager);
}
}
此類是信息專家,僅負責創建WorkspaceItemViewModel實例。它具有使用new關鍵字的權利,并且具有WorkspaceItemViewModel依賴關系的知識。您可能希望使用接口隔離 ViewModel,但在您的用例中價值可能很小。歸根結底,您使用 IoC、DI 和接口隔離是有原因的,當它們停止為您的特定應用程序提供價值時,它們的使用就會變成噪音。
您的視圖模型可以使用以下內容:
public class ExampleViewModel : ViewModelBase
{
public ExampleViewModel(IWorkspaceItemViewModelFactory workspaceItemViewModelFactory)
{
AddItemCommand = new ActionCommand(() =>
{
var newItem = workspaceItemViewModelFactory.CreateWorkspaceItem();
WorkspaceItems.Add(newItem);
});
}
public ICommand AddItemCommand { get; }
public ObservableCollection<WorkspaceItemViewModel> WorkspaceItems { get; } = new ObservableCollection<WorkspaceItemViewModel>();
}
- 1 回答
- 0 關注
- 198 瀏覽
添加回答
舉報