我們第一步就是去了解三層架構和問題然後去看MVVM是怎麽去解決這些問題的。

現在，感覺和事實是完全不同的兩個東西。當你看到三層架構的框圖的時候，你會覺得每層的職責被分配的很好。但是當你你真的去寫代碼的時候你會發現其實一些層被迫去做本不應該他們做的額外的事情（違反了SOLID原則的S）。

這個額外的工作就是在UI-Model和Model-Data access之間的代碼。讓我們就把這些代碼稱為“GLUE”代碼。有兩種主要的邏輯會造成“GLUE”代碼（也許我知道的並不夠多，其他的可以自己發現）：

1.映射邏輯（綁定邏輯）：每一層通過屬性，方法，集合來和其他層進行通信。舉個例子，一個在UI層的叫做“txtCustomerName”的textbox和customer類的“CustomerName”屬性進行關聯。

txtCustomerName.text=custobj.CustomerName;//mapping code

現在誰擁有上面的綁定邏輯代碼，是UI還是Model層？開發者一般把這個代碼推到UI層。

2.轉換邏輯：數據格式在不同的層是不一樣的。比如，一個“Person”類有一個叫”Gender“的屬性又包含“F”和“M”，但是在UI層，我們希望看到一個checkbox，“checked”（true）代表male，“unchecked”（false）代表female。下面是一個轉換的示例代碼。

if(obj.Gender==”M”)//transformation code
chkMale.IsChecked=true;

else

chkMale.Ischecked=false;

大多數的開發者會在UI層寫這樣的“GLUE”代碼。為了把這些代碼分的詳細一般可以在背後的代碼找到答案，比如.cs文件等。因此如果先”xaml”然後”xaml.cs”會有粘合代碼，先”aspx”再“aspx.cs”也會有粘合代碼等等。

現在有一個問題：粘合代碼是UI的職責麽？讓我們來看一個WPF程序的例子和粘合的代碼的細節。

下面是一個簡單的”Customer”模型類，有3個屬性“CustomerName”,”Amount”和”Married”字段。

但是這個模型在UI層展示的時候，它和下面展示的一樣。因此，你能看到它包含模型的所有字段同時也加上了一些額外的東西，看color label 和 married check box。

下面是一個簡單的圖表，左邊是模型的字段，右邊是UI的字段。中間是關於映射和轉換的邏輯的描述。

你可以看到前2個字段我們沒有任何的轉換邏輯，他們只有映射的邏輯。其他2個字段映射和轉換的邏輯都有。

轉換和映射的邏輯通常都在後臺代碼中，就如“XAML.CS”。下面就是上面customer screen的後臺代碼，你可以看到映射代碼，顏色的判斷代碼和性別格式轉換代碼。我給代碼添加了註釋方便你可以看到哪是映射代碼，哪是轉換代碼。

現在圍繞GLUE代碼有幾個問題：

1.違反SRP:這樣的GLUE代碼是UI的職責麽？如果你知道了當時的情況，在amout的值改變的時候，UI的代碼也要做出改變。那為什麽當數據改變的時候我需要去改變我的UI代碼。似乎可以嗅到不良代碼的味道。UI應該是只有在我改變styles,colors,positoning等的時候才會要改變。

2.重用性：如果我想把同樣的顏色邏輯和性別轉換用在下圖這樣的一個編輯的界面上，我怎麽去做呢？我去復制粘貼去創建重復的代碼？

假如我想去領先一步把粘合代碼用在不同的UI技術上，像MVC,Windows form 或者mobile。

但是由於UI背後的規範和UI技術關系很緊密，這樣跨不同UI技術的重用事實上是不可能的。

例如，下面的代碼是繼承自“Window”類。”Window”類和WPF UI 技術關系很緊密。因此，如果我們想把這個邏輯用在Web應用或者MVC上時，我們怎樣去創建一個這個類的對象並且去消耗它。

public partial class MainWindow:Window
{

//behind code is here

}

我們怎麽去重用後臺代碼？我們怎麽去遵守SRP?

WPF MVVM 架構 Step By Step(2)（簡單的三層架構示例及粘合代碼GLUE code）