HTML 5+ CSS 3 會殺了Flash 跟Silverlight ? -2

會拿Silverlight跟Flash比較的人，基本上，不懂Silverlight.....

從Silverlight 2開始，我在所有的文章與研討會中就明白的揭示了，"Silverlight是網際網路應用程式開發技術" 的觀念。在VS 2010中，不需要使用Microsoft Blend，就可以直接開發Silverlight的表單操作介面，同時Silverlight Application也可以直接支援Windows、Forms以及SharePoint的驗證，再加上WCF RIA Services的支援，基本上只要會C#的開發人員，不懂HTML、JavaScript，也可以快速的開發出豐富的網際網路應用程式。再加上容易除錯與VS 2010提供了方便的開發環境以及跨平台的支援(Mac、Windows、Linux、WM7)，只要微軟好好發展下去可望成為.NET網際網路應用程式開發的另一個主流。

記得當年HTML剛出來，大家有跑馬燈(<marquee/>)可以用，覺得超新奇超炫的，一時之間每個網站幾乎都有跑馬燈的橫條在上面跑的情況。時至今日，有多少人還在用? 所謂的標準，真的就是符合大家使用的準則，抑或是限制技術成長的濫觴? HTML 5 跟CSS 3的出現，目前獲益最大的應該是這兩家公司：

1. Apple：原本不想支援Flash，但是使用者又想看Flash做出來的效果。

2. Adobe：想不到吧! HTML 5+CSS 5讓Adobe不需要追著瀏覽器去提供新的擴充套件，還可以出新版的CS賺錢。

前一篇也已經說明過了，要叫瀏覽器做更多的事，就必須要有更複雜的瀏覽器的道理。現在所有的個人電腦瀏覽器都有Flash套件可以支援，因此瀏覽器有沒有支援HTML 5 我不相信目前會有多少人care；但是行動裝置則未必。HTML 5 既然是標準，行動裝置製造商就可以直接從作業系統中去支援這一個標準，提供原生的網際網路多媒體存取環境，避開瀏覽器的效能問題；而這一塊也不是目前Flash主攻的市場，因此HTML 5要從此切入，才會有比較大的發展空間。

WCF Service的介面設計

WCF Service 透過Service Contract提供服務的介面給Client端的應用程式使用。常常會有人問我，如果WCF Service的服務介面需要修改，應該要怎麼辦的問題。如果從元件的角度出發來看的話，介面修改相對的所有使用該元件的應用程式也都必須要跟著被修改，這對於可能會需要隨著企業邏輯做調整的WCF服務來說，會造成不小的影響

在繼續這個話題之前，先請大家思考一下，如果你家的電器插頭，每一種電器插頭的規格都不一樣的話，會是怎樣的世界?

從這樣的角度去思考的話，服務的介面規格當然是設計的越簡單越好。微軟所提供的Design Guideline中提到：

• Avoid tight coupling across layers.
• Design coarse-gained operations.

對於90%以上的服務來說，我們需要兩個基本的功能：

1. 執行指令並回傳運算結果或是錯誤資訊。

2. 確定目前服務是正常的。

根據這樣的出發點，我們可以設計出一個通用的WCF Service介面：

[ServiceContrract]

public interface ICommonService{

[OperationContract]

object Execute (string command, Dictionary<string,object> parameters, out string errorMessage);

[OperationContract]

bool Diagnostics ();

}

在這樣的介面設計之下，你的服務不管要增加多少功能，或是要減少功能，都不會需要更動到服務的介面規格，只需要支援新的command指令即可。但是需要注意的是，因為在這個服務介面規格中是使用object型別傳遞資料，因此你必須要另外再使用Data Contract宣告可序列化物件，然後透過ServiceKnownType將該物件定義加入WCF服務規格中。