通過添加視圖狀態功能來修改現有MVVM基礎結構

我將在現有的MVVM WPF應用程序中引入視圖狀態功能。目標是能夠保存並加載（恢復）控件的特定狀態。通過添加視圖狀態功能來修改現有MVVM基礎結構

這個問題更多的是關於系統靈活性/維護性方面的設計和最佳解決方案。

目前的基礎設施：

public abstract class ViewModelBase 
{ 
    protected ViewModelBase(...) 
    { 
    } 
} 

// and few more very the same ViewModel classes for different control types 
public sealed class GridViewModel : ViewModelBase 
{ 
    protected GridViewModel(...) 
     : base(...) 
    { 
    } 
}

我介紹IViewState interface所以每一個具體的視圖模型可以提供自己的實現像GridViewState class並打算把它在視圖模型基礎設施方式如下：（想法是通過類型ViewState中作爲泛型參數）

public abstract class ViewModelBase<TViewState> 
    where TViewState : class, IViewState 
{ 
    protected ViewModelBase(...) 
    { 
    } 

    public TViewState ViewState { ... } 
}

這是個好主意附上查看小號tate功能到ViewModel？
這是一個很好的解決方案，通過像class GridViewModel<GridViewState>這樣的泛型類型參數在特定的ViewModel typa和ViewState之間引入綁定關係嗎？
哪裏和爲什麼最好定義像LoadState()/SaveState(),IViewState本身或ViewModelBase這樣的方法？
還有其他的設計方案嗎？

來源

2011-09-12 sll

對我來說看起來很合理。 –

1和2看起來是合理的 3. LoadState（）和SaveState（）更接近於IViewState，但是爲了可擴展性和可維護性，提供了一個持久化接口來解析存儲到，這允許實現多個持久性具體實現（例如數據庫，xml，文件，ws，...） –

關於加載/保存狀態我通過創建封裝ViewState +兩種方法的IViewStateAware 將它與狀態本身解耦。 – sll

有沒有理由不堅持你的域對象，只是從它們加載時重建ViewModels？你的觀點認爲你的域名不會是什麼樣的狀態？如果它與視覺元素（如位置和位置）有關，我會將它們推入設置類並堅持。

我假設有一些潛在的邏輯和類代表你的域，如果不是那麼你的ViewModels真的是你的域名和你的想法是堅實的。

我可能會看有點像memento模式來補充水分，你的虛擬機，因爲他們很可能有一個公平的幾個事件和其他關係（例如改變性質的藏品事件）不能被序列化，並且必須是重建。

有很多持久性模式，但由您的命名和解釋紀念看起來很合適。

來源

2011-09-13 12:12:38 JRoughan

ViewModel是一個複雜的實體，它不是由單個域實體表示的。 ViewState應該保存像排序，列順序，用戶佈局偏好等UI設置，這是由ViewModel表示的數據的10％。 – sll

虛擬機通常代表多個域實體，但通過對這些實體進行再水化，仍然可以回到當前的虛擬機狀態。如果有純粹的視覺元素需要堅持，那麼您是否有理由不創建一個用戶首選項對象，並像對待任何其他域實體一樣對待它？ – JRoughan

不，還有其他的實體，他們是商業實體，也有一些定製標準保存到設置 – sll

通過添加視圖狀態功能來修改現有MVVM基礎結構

回答

相關問題