MVVM備用事件模式

我現在有看起來像這樣的MVVM備用事件模式

MainWindowViewModel 
    TabViewModel 
     EditorViewModel 
      ReviewingServices 
       ConflictFinder

我遇到的問題是，TabViewModel希望被通知的衝突（從ReviewingServices）的等級以及其他的東西。我可以創造我所有的依賴公共getter和訂閱任何我想要與DependencyA.DependencyB.DependencyC += SomeHandler;但這是相當混亂。我發現自己創造了太多我想數的事件。本質上，我創建了一個凌亂的事件網絡。我喜歡我爲每個班級創建的責任分離，但是每個班級都有2-3個活動，每個班級都很難維護。如果用戶只有1級以上，我沒有創建和維護事件的問題。當說MainWindowViewModel希望被通知的新的意見（從ReviewingServies公佈的亂來。

有沒有做這些類型的事件好不到哪一個用戶可能想訂閱被深深嵌套在應用程序事件？

來源

2011-08-11 gcso

我不知道如果我真的有你的麻煩，但我建議看一些類型的事件聚合器，試着檢查出Caliburn one，但也不是那麼的不同實現一個自己。有了這個，你命名事件與類型和來自世界各地的訂閱。

來源

2011-08-11 16:09:43

嘗試使用微軟棱鏡和他們的事件聚合

來源

2011-08-11 16:12:44

鏈接DependencyA.DependencyB.DependencyC通常被認爲是打破了Law of Demeter（你實際上依靠的依賴的依賴，等等）。

我最近通過使用由作爲IMyOperationNameContext這樣的接口，其允許我分享/噴射兩種的ViewModels與/組合上下文成採用第三視圖模型和所有的一個WinForms控制限定的Mediator解決了類似的設計問題而無需將三個模型直接耦合在一起。

像這樣的東西（注意是怎麼樣的IAlbumContext行爲更象是一個代理，但是這只是因爲樣品被簡化）：

interface IAlbumContext 
{ 
    public AlbumInfo SelectedAlbum { get; set; } 
} 

class AlbumContext 
{ 
    AlbumSelectionViewModel _model; 

    public AlbumContext(AlbumSelectionViewModel model) 
    { 
     _model = model; 
    }  

    public Album SelectedAlbum { 
     get { return _model.Album; } 
    } 
} 

class PhotoUploadDialog : Dialog 
{ 
    public PhotoUploadDialog(IAlbumContext context, PhotoUploadViewModel viewModel) 
    { 
    } 
}

雖然這種解決方案爲我工作，我喜歡它的同高內聚性和解耦，最終不會大規模擴展（例如，根據應用程序，這種上下文接口的數量可能會迅速增長）。然而，如果採用更通用的解決方案，則權衡是代碼難以遵循。

來源

2011-08-11 16:26:12

MVVM備用事件模式

回答

相關問題