Why Master Page, But Not Frameset?

首先，要做出全站一致的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)

引用自"黑暗執行緒"
http://blog.darkthread.net/post-2007-11-18-why-master-page-but-not-frameset.aspx