iPlace: 1月 2010

[轉載]Published 18 November 2007 06:30 PM 由 Jeffrey
跟同事討論新網站如何讓所有網頁都保持一致的Header/Menu/Footer，我的看法是回歸ASP.NET 2.0建議使用的Master Page、同事則覺得這樣比較笨重，不如保持用FrameSet切割出一塊Frame切換內容的傳統做法即可。想了想，到ASP.NET 2.0後，看到的幾乎都是用Mater Page解決，VS 2005 IDE甚至會在你使用FrameSet時發出警告；另外一方面，除了ASP.NET之外，印象中現在Internet中遊歷到的大小網站，除了一些上了年紀的簡單小網站，已經很難看到用Frame切割Header/Menu的做法。雖然腦中大致了解二者間的差異，但Frame式的設計似乎已快從地球上絕跡了，為什麼?

好奇地針對這個問題，Google了一下，以下是我的心得。

首先，要做出全站一致的Header/Footer，有幾種做法:

•Copy & Paste大法! 把Header/Menu/Footer的Code複製到每一個網頁。
(你瘋了嗎? 誰敢給我用這種方法設計網站，我一定用鍵盤打爆他的頭!!)
•Frameset: 每次只更換Content Frame網頁，缺點是會有Cross-Frame Scripting的Issue，而且有可能Frame間更新狀態不同步。
•利用Server-Side Include: 可用在ASP，但每一頁都要配合排版位置插入。
•利用User Control: 可用在ASPX，但每一頁要配合排版位置擺放。
•Master Page: 利用類似繼承的概念，內容頁不必過問Header/Footer的排版設計，但每次執行都要重新產生Footer/Header元素。
以上這些做法，在ASP.NET 2.0中，大概只剩下Master Page及Frameset兩種要抉擇。Master Page可以確保直接使用內容頁的URL也會看到完整的版面設計，用Frameset則可能瞧見沒有Header/Footer的裸體版內容頁，這在Search Engine點選查詢結果時最可能發生。但Master Page的每一頁都要重新載入、產生及傳輸Header/Footer也是不爭的事實，比Frameset有更多無謂的消耗。

找到一篇不錯的剖析，列舉了採用各架構的最佳實務:

Master Page

•不介意每次全頁更新
•需要彈性化的繼承式版型設計，且使用者不在意全頁更新
•希望每一頁都被獨立檢視時，都可以完整呈現
ICallbackEventHandler

•只想局部更新頁面的部分資料或圖片
•只想局部更新頁面上一些簡單的HTML元素(不含asp: Controls)
XML Data Islands

•在Client建立資料儲存，建少網頁點擊更新次數
FrameSet

•不希望全頁更新
•具有複雜的網頁元件，必須從Server端產生更新(不能只換Data)
•網頁上不同的區域需要用不同的頻率更新
不過，由這些分析，我還是無法理解大部分網站捨棄Frame的理由，看到不少人說"Frames Are Evil"(相信嗎? 居然有個"我恨Frames俱樂部"!)，卻沒足夠的理由讓我完全信服。我所知道Frame的缺點包含四點:

1.Cross-Frame Scripting比較曲折，但只要不是Cross-Site，並不難解決。
2.Frame間可能發生更新不同步，例如: Header Frame的Logon User與Content Frame的不是同一人。
3.Browser顯示的URL無法準確反應內容Frame的變動，譹Brower的標籤功能(IE我的最愛)頓成廢材。
4.當使用者使用Content Frame用的URL連上網站，看到的不是完整網站呈現版型。目前Search Engine記錄及Index的特性，這種狀況挺常發生的，但我不敢斷定這就是Frame漸漸被揚棄最主要的理由。
於是我又做了些挖掘，看看可否找出Frame有更多我不知道的黑暗面? 以下是我又挖到的一些補充:

•Frame讓Browser的列印功能變得不直覺
•Frame導致Browser的Refresh行為與使用者的預期有出入
不過，歸納了以上的種種剖析，我認為Frame有些缺點，但罪不至死，不需反應過度。在某些情境下，用Frame仍OK，如果:

•網站為內部使用，不在乎Search Engine Friendly
•Header/Menu/Footer的演算及HTML很複雜，值得省下這個資源成本
•User連線頻寬有限，需要儘可能減少資料傳輸量(Update 2007-11-19)

至於我，應該還是會回歸Master Page，理由是盡量用別人在用的方法做事，出問題時可以多些難兄難弟，也多點相關討論可以參考；萬一被Challenge時還可以說，"嘿! 別怪我，我是照著微軟建議的方式處理的"，然後把頭埋到沙子裡繼續睡午覺，哈!!

來自亞特蘭提斯 .NET Atlantis 明仔著
到目前為止，.NET CF 4.0 (.NET Compact Framework) 都沒有任何消息，雖然VS2010 RC推出日期是TBA (原定2月中,但已証實Delay)，但就正如我之前所說，.NET CF 4.0是Windows Mobile最後希望，即使未來.NET CF 5.0會有什麼大更新都不可能追過iPhone平台或者Android。
但現在WM已經在垂死邊緣，WM6.5對End User和開發者都沒有驚喜，WM7推出遙遙無期，HTC都開始推Android多過WM。

而且iPhone和Andriod的勢頭實在太強，到處都是相關討論，我想是時候去研究一下其他平台。
如果你和我一樣都想從iPhone和Android中，二擇其一的話，定必要看看以下兩篇文章。
軟體商怎選Apple iPhone與Google Android？
Android versus iPhone Development: A Comparison
http://www.zdnet.com.tw/enterprise/technology/0,2000085680,20137151-1,00.htm
http://greensopinion.blogspot.com/2009/07/android-versus-iphone-development.html

特別是zdnet那一篇，其實我都幾同意，iPhone的門檻較高，先要買部Mac機，學用Mac之餘，再買XCode IDE，再來就是學Objective-C，
而Android就較易入門，Eclipse CDT加上ADT就可以，語言方面則是Java。

我個人則對Android比較有興趣，如果你打算開始的話，我建議先看看這篇文，除了固有Java的Class之外，還有Android的API，和軟件架構。
Android開發筆記
http://code.google.com/p/androidbmi/wiki/DiveIntoAndroid