2012-10-14 53 views
0

我正在過度考慮這一點,讓自己陷入混亂,但無法清除我的頭。MVVM使用UI的構造函數來傳遞模型

我是WPF新手,我正在嘗試熟悉MVVM。我理解這個理論。我需要一個視圖,一個模型和另一個模型(稱爲視圖模型)。

但是,如果我的模型是由視圖的構造函數的參數構造的,會發生什麼情況。

因此,假設我有一個完全空白的項目,唯一的事情是我一個重載的主窗口構造函數取模型:

public MainWindow(Logging.Logger logFile) 
     { 
      InitializeComponent(); 
      this.DataContext = logFile; 
     } 

型號是日誌文件。如果我沒有單獨的Model類,我仍然可以實現MVVM嗎?

任何想法將不勝感激。

+0

我個人完全不明白你在問什麼。 – Jon

回答

2

你正在推翻這一點。

有幾個組件MVVM:

檢視:

視圖提供上的數據,以及,圖。

視圖模型是存在的組織你的數據,以便您可以組織數據的一個或多個源成可以被看作一個連貫的結構:視圖從視圖模型

視圖模型中獲取數據。視圖模型也可以執行基本驗證。 ViewModel對UI沒有理解,因此不應包含對控件,可見性等的引用。視圖模型從服務中獲取其數據。

服務:

服務提供來自外部來源的數據。這些可以是WCF,Web服務,MQ等(你會明白)。服務返回的數據可能需要進行整形,以便可以在UI中顯示。爲此,您需要從服務中獲取原始數據並將其轉換爲一個或多個Model對象。

型號:

甲模型對象是已被創建,使得其可以很容易地顯示在與UI /工作的對象。

您可能會發現,您不需要塑造來自您的服務的數據(幸運的是),在這種情況下,無需創建模型對象。你也可以決定你不希望你的服務直接與你的視圖模型對話,而是讓他們通過「中介」對象獲得他們的數據。在某些情況下(通常當您從源/多個源接收連續的數據流時)也是很好的。

MVVM有點像粥:有很多潛在裝飾可以添加,但你不一定需要全部添加它們。或者想要。

這有幫助嗎?

編輯:只是偶然發現了這個:MVVM的更深入的表達:Mvvm Standardisation。這也可能有用

+0

我的服務是通過UI的構造函數提供的,因爲logFile是僅存在於內存中的對象。也許我需要將日誌文件保存爲XML並將其稱爲服務? – Dave

+0

你在使用依賴注入框架嗎? –

+0

目前,完全沒有這樣的東西 - 這是一個簡單的WPF項目和幾個類庫 - 我不使用數據庫或這樣的服務,因爲它是一個榮耀的複製和粘貼程序!你的想法是什麼? :) – Dave

1

該模型是ViewModel將知道的事情,但不是視圖。如果您需要提供有關Logger的信息,您當然可以擁有一個LoggerViewModel,該LoggerViewModel知道Logger,然後View逐漸瞭解ViewModel。有幾種方法可以做到這一點,並且在視圖構造器中設置DC就是其中之一。

在瞭解誰知道誰,MVVM架構模式,IMO的真正含義之後,ViewModel通過數據綁定與View進行通信。沒有更多,也沒有少。很多好吃的東西都出來了,但這是它的關鍵,它使得它不同於其他關注模式的分離(如演示模型,MVP等)

這就是說,你需要感受它通過一些示例項目工作。當你遇到困難時,在這裏提出問題是很棒的,但你必須意識到你的問題最好是有點模糊。另外,除非您真的想在視圖中顯示日誌信息,否則日誌記錄不是MVVM關心的問題。它有趣的好處,但不是MVVM。

谷歌喬希史密斯的MVVM演示在MSDN上的一個完美的肉類但平易近人的開始類項目。當他們出現時,請提出更多問題或改進它們!

HTH,
Berryl

1

忘記的觀點!至少在一開始;)

試着想想你想要什麼和你需要什麼。我的理解是你想處理一個日誌文件。所以你需要一個視圖模型。

public class LoggerViewmodel{} 

你可以把日誌文件作爲參數傳遞給vm ctor。現在你必須考慮你想用你的日誌文件做什麼?爲你想要的任何東西創建一個屬性(LastModified,LastRow,無論)在你的viewmodel。

BTW有一兩種不同的方式做MVVM,首先是鑑於第一,另一個是視圖模型第一。我在我的項目中都做了這兩件事,並按照我的需要採取適合更好的方式(視圖模型首先是最多時間;))。

請編輯你的問題,並添加你想要做的日誌文件,然後我們可以給你一個更好的答案。

編輯:

我還可以實現MVVM的時候,我沒有一個單獨的模型類?

以簡短的方式回答你的問題 - 是的,你可以。您必須分離視圖和視圖模型,並使用綁定將視圖綁定到datacontext(viewmodel)。

+0

謝謝你。這將有助於未來更好地考慮項目 – Dave