VM解析成本高嗎？ MVVM Autofac

Question

我們有一個 WPF MVVM 應用程序，我們使用 Autofac 作為我們的 DI IOC 容器。 我們注冊視圖模型並在運行時解析它們。

我意識到我們所有的視圖模型和子視圖模型和子視圖模型的所有構造函數都在程序開始時運行。 正如你所料，我猜。

我們的虛擬機通常需要從數據庫中獲取數據，因此我們使用“假構造函數”方法 LoadAsync() 來完成繁重的工作。

視圖模型通常看起來像這樣

public class MyVm : BaseViewModel {
    //... lots of fields and properties

    public MyVm(SubVm1 sub1, SubVm2 sub2, Repository1 repo1, SomeService svc){
         this.sub1 = sub1;
         this.sub2 = sub2;
         this.repo1 = repo1;
         this.svc = svc;
    }
}

我正在嘗試決定我是否喜歡這種設置。

我想到了 ViewModelLocator，但后來我無法通過構造函數輕松識別 class 的依賴關系。 但我可以延遲 object 的創建，直到實際需要 subVm。

我想過只是注入一個工廠方法，保留延遲，保留信息。 使用 autofac 很容易設置，但對我來說看起來很奇怪。

歸結為在啟動時實例化這些類型的類的成本是多少。 我讀到 object 的創建在 C# 中真的很便宜，但是如果我有很多字段和屬性，它仍然很便宜嗎？ 如果我們最終在應用程序開始時創建了 100 多個視圖模型怎么辦？

Answer 1

所以在我的工作中，我們有一個 C# wpf 應用程序。 我們的啟動順序如下：

• 初始化數據庫 (EF6)
• 注冊所有服務
• 注冊所有視圖模型

視圖模型可以嵌套的地方。

視圖模型由視圖模型的構造組成。 在這種方法中，視圖模型還構造任何子視圖模型，例如對於數據網格，控制類似的東西。

然后我們有一個帶棱鏡的機制，我們在每個視圖模型上有 2 個處理程序，用於OnNavigatedTo和OnNavigatedAway ，當用戶切換到屏幕或從屏幕切換時調用它們。 在這些函數中，大部分更新和清理邏輯都駐留。 因此，ctor 將創建一個與邏輯交互的管理器，然后僅在我們的 onNavigateTo 中我們執行實際的數據獲取。

創建 object 非常快，而且由於我們傾向於使 ctor 遠離長時間運行的函數（db 調用等），因此大多數時間大約是我們服務的 init 的 20 倍。

我們為模塊創建了大約 15 個屏幕，每個屏幕大約有 5-10 個面板（因此這些面板嵌套在我們屏幕的視圖模型中），每個面板可以有大約 1-10 個控件。 然后我們還有另外 30 個左右的額外屏幕用於其他內容。

所以我們有相當多的視圖模型，它們可以變得相當大，但是因為大多數資源密集型項目都不在那里，所以負載非常小。

我不知道這是否能回答你的問題，但這應該會給你一個更好的見解，我希望它有所幫助。

在你的情況下，我也會這樣做。 您當然可以轉向更異步的方式，但我認為增加的復雜性不值得。 如果我們測量到它們花費的時間太長，啟動需要幾秒鍾，並且對於應用程序和開發來說，這似乎非常好，我們會定期使用異步優化我們的服務。

只記得; 在測量之前不要進行優化，並確保您對客戶在啟動時間方面可以接受的內容有一個很好的了解。