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

我們第一步就是去了解三層架構和問題然後去看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?

繼續閱讀