適用范圍]
本文所述的原則、建議適用於大型企業信息門戶網站的設計和開發，注意不是小型企業網站、一般企業電子商務網站、企業級Web應用系統。
[
一般性原則]
一、網站設計原則 第一原則：內容豐富、明確
網站主要是為浏覽著提供信息服務的，作為大型企業信息門戶網站，必須首先提供種類繁多內容豐富的資訊，使不同的訪問者都能夠訪問到自己想要的信息。但是信息多了自然繁雜，因此有針對性地為浏覽者提供明確的內容是很重要的。
第二原則：界面設計良好
內容需要良好的界面設計來展現，良好的界面設計能夠讓浏覽者賞心悅目，能夠感受到明確的網站風格和主題，甚至感受到企業的文化底蘊，從而留下深刻的記憶，並為他進一步探索發現和使用網站提供的功能提供感官和心理上的意願。
[題外話：]作為Web應用程序的開發人員，往往不注意這個特點而專注於“功能設計”。
第三原則：功能適用、易用
網站提供的一切功能都是為浏覽者服務的，提供強大的而富於特色的功能可以使浏覽者更方便的獲取他需要的信息和服務。比如提供網上產品訂購的服務，提供一個強大的產品檢索功能是很必要的。功能也不是越多越好，有可能讓浏覽者無從選擇，就好像現在的手機，可能絕大多數人還是打電話和收發短信，其他一些比如無線上網等功能並不適用。同時，功能如果不易使用，操作繁瑣，甚至容易令人誤解，那麼再強大的功能都是沒用的。作為企業信息門戶的浏覽者可能並不是都能熟練的使用計算機，不能要求他們像企業級Web用戶那樣去完成復雜的操作，解決一些使用中可能出現的問題，要求任何一個功能都要容易使用，好用。
上訴三原則，為著名的“Web設計三原則”，同時由於三原則的優先級和重要性，像一個金字塔般，因此也叫作“Web設計金字塔”。
二、網站結構設計原則 合理的導航設計：
在門戶的首頁需要一個合理的導航設計，比如欄目導航，內容導航，用戶功能導航等，具體怎麼使用根據網站的功能定位和設計定位決定。頁面導航的層次不能太深，一般來說最多讓用戶點擊三次鼠標就能夠找到他想要的頁面。
良好的目錄結構：
一般來說按照網站功能/欄目劃分一級目錄，子功能/二級欄目劃分二級目錄，圖片可以放在專門的目錄等。目錄層次不宜過深。搜索引擎一般都是對目錄結構的深度來評判網頁的價值的，這對於企業網站來說很重要。
網站內容索引：
如果信息量太大，需要對每一個欄目/頻道做內容索引，不同於導航設計，內容索引記錄了內容摘要、關鍵詞、相關信息等，方便內容檢索。比如有的網站的“網站地圖”。同時該功能也是搜索引擎最愛訪問的地方。
三、網頁設計原則： 速度第一
沒有人有耐心去打開一個很久才能浏覽的網頁，故有一個“三秒原則”，如果一個網頁在三秒種內都打不開，那麼訪問者就會失去耐心放棄當前頁面的浏覽。
頁面盡可能小
頁面的大小跟訪問速度是成正比的，根據速度第一的原則，那麼就要做到每一個浏覽的頁面都要盡可能的小，少占網絡帶寬，訪問速度才可能快。這裡的小不僅僅指Html代碼少，也包括圖片數量少，單個圖片占用磁盤空間少。
使用CSS
盡管可以直接設置頁面元素的表現樣式，但網頁統一使用CSS可以更容易的統一網站風格，同時減少網頁代碼大小。
少用Flash和大型圖片
別的不說，就是因為他們可能會占用大量帶寬。
慎用框架
不能說所有人都在使用最新版本的浏覽器，而且不同的浏覽器對框架的支持也可能不同，另外不是所有的搜索引擎都能夠很好的訪問框架頁面。
鏈接清晰
不能讓浏覽著不知道他在那裡，也不能讓浏覽著找不到回去的路，每一個鏈接都要明確浏覽著想要去的地方和想要訪問的功能，更不能有死鏈接。
四、系統架構原則： 提供快速的系統訪問
包括客戶端的浏覽和服務器端的通訊/數據訪問，都只有一個原則，就是“快”。可以采取集群技術，緩存技術，負載均衡技術等 。
穩定的運行
不能出現時不時無法訪問或者訪問數據很慢。這需要采用上面的技術確保在大容量並發訪問的時候系統仍然能夠穩定的運行。
安全可靠
確保數據不會丟失、洩密、損壞。如采用多層服務器訪問，數據加密技術，安全信道等方式。
[
開發設計建議]
根據上面的“一般性原則”，可以采用本文下面的一些建議。注意這些建議都是一般性的，不是特定的，需要根據實際情況具體運用。
限於篇幅，本文主要說一下在采用.Net開發企業信息門戶網站所要注意的問題。
一、網頁設計相關：
1，做好頁面布局和內容規劃，只放置合適的內容，並盡可能使頁面設計的最小。
2，使用好的網頁編輯器，如DW，FP，不要用VS自帶的編輯器，因為它會產生很多無用的沉余代碼，而且設計的界面也不是很好看。
3，小圖片采用GIF格式，下載速度最快，大一點的采用jpg,占用磁盤空間小。
4，盡可能使用CSS，這既是原則也是方法，可以使整個網站浏覽速度提高3%以上，有的甚至能夠提高30% 。
5，盡量不要使用框架，在需要的地方也要有替代措施。
6，不要只針對IE寫客戶端腳本。
7，客戶端的事情盡量在客戶端處理。現在客戶端設備已經很強了，許多原來在服務器端才能做的事情現在都能在客戶端做，而服務器端反而成了訪問的瓶頸。
8，少用Flash。Flash一般都會占較大的網絡帶寬，在需要的時候也要注意不要做得太大用的太多。
9， 避免使用彈出式對話框，因為現在好多浏覽器都被裝上了“彈出窗口攔截”插件。說服用戶解決這個問題有時是很惱火的，因為他們不是都能熟練的使用計算機。
二、.Net設計相關
1，能用Label的地方不用TextBox，因為Label比起TextBox來說是輕量級的控件。
2，盡量使用Repeater 控件綁定列表數據，有兩個原因，一是可以保留美工原始的界面設計效果，二是比起DataGrid控件，性能可以提升70%（有專門的測試案例）。
3，如果頁面僅僅是浏覽不用回送服務器端繼續處理，那麼不要使用頁面視圖VIEwState。如果一個界面上有很多控件那麼視圖將會占去一半的頁面大小。其他情況也要盡量少用頁面視圖。
4，采用緩存技術。從緩存位置可以分為客戶端緩存、代理緩存、服務器端緩存；從具體頁面來說可以分為整頁緩存、局部緩存、數據緩存。緩存技術可以極大地提高Web服務器的處理能力，是最經濟有效的提高訪問速度的措施。
5，靜態頁面生成技術。如果采用緩存不能起到很好的作用那麼可以將經常訪問的頁面生成靜態頁面。像三大門戶網站都采用了這個技術，很多CMS也都采用了該技術。
6，服務器處理數據，客戶端負責展現。把客戶端的事件放到服務器端去處理在互聯網上不是好注意，不能想象這是一個企業內部的Web應用程序。
7，少用Session。如果要在頁面之間傳遞參數，可以采用URL方式或者頁面視圖方式，如果是跨頁面的數據傳遞，那麼也最好使用CookIE 。Web訪問的特點決定了這個多用戶並發訪問環境，Session會占用很多服務器資源，如果訪問量很大這個資源占用是很高的。
8，合理使用Application 。不同於緩存對象，它能夠提供更好的全局數據訪問，適合於需要長時間緩存頻繁的公共數據。
9，注意CookIE 問題，有的浏覽器可能不支持使用Cookie 訪問你的站點，在使用CookIE 之前一定要檢測客戶端是否支持並采用相應的策略。
10， 只訪問需要的數據，現在AJax技術可以很好的處理這類問題，它讓頁面處理速度更快表現力更豐富。
三、數據訪問相關
1，優化數據庫結構設計。這是數據訪問效率和編程復雜程度的關鍵。沒有良好的數據庫結構設計其它都談不上。包括字段類型的選擇，表的結構，索引的使用，表的關系等。
2，優化數據庫物理設計。這裡關注的是數據庫容量，日志，磁盤使用，數據備份機制，數據訪問機制，安全等數據庫物理結構相關的問題。
3，合理設計“主鍵”：在不同的場合需要采用不同的主鍵設計策略，在互聯網大容量並發訪問的環境中，建議主鍵采用整形自增字段。主鍵使用還應該遵循“無意義”原則。
4，采用最佳的數據訪問接口，如專門針對SQL Server的數據訪問對象。
5，“只要需要的數據”：如果一行有大容量字段，那麼讀取一整行效率是非常低的（數據瓶頸）。
6，最遲打開，最早關閉的原則。使用數據庫後一定要及時關閉連接，它們是系統昂貴的資源。
7，采用“數據緩存”技術，將經常使用數據集緩存在磁盤或者內存中，盡量減少對數據庫的直接訪問。
8，使用存儲過程。
可能在一般的應用系統中存儲過程可以被簡單的查詢替代，因而更“通用”，但是我們現在討論的是大型企業信息門戶網站的問題。作為一個互聯網應用系統，處理速度和網絡帶寬無疑是最重要的。系統的瓶頸往往是磁盤IO和網絡IO，合理使用存儲過程使得分布式系統結構效率大大提升。但也要注意合理使用，比如避免一般的分頁過程，由於查詢會有很多，使得這樣的存儲過程太多而管理混亂。
9，慎用游標。數據庫的游標執行效率一般都比較低，一般都可以使用復雜的查詢語句代替，合理的數據庫結構設計也可以避免這個問題。
10， 合理使用觸發器。大部分人覺得觸發器使得數據關系不明確，即屏蔽了數據的關系，但是當一個系統非常復雜的時候，數據關系更是復雜，這時候使用觸發器來維護數據的一致性和數據同步的功能，可以有效地屏蔽數據關系的復雜性，減少程序代碼。
11， 合理使用事務：如果不是需要連續處理的或者需要特別安全的數據處理，不要使用事務，因為事務的使用會影響數據庫的並發性能。單純的查詢過程也使用事務更不可取。
12， 安全的數據訪問：目前十分常見SQL注入式攻擊，需要注意數據庫系統安全設置和Web程序編碼問題引起的安全漏洞。
總結：數據訪問的性能決定性的影響了系統的整體性能，數據庫結構的設計也會極大地影響到程序代碼的復雜性。現在有的人認為在網絡速度和磁盤容量大大提高的情況下還來考慮數據訪問的問題有點不切實際，但是他們忘了我們現在面對的是成千上萬的用戶。
四、系統架構相關
這個比較復雜，這裡只是簡單的說說需要注意的問題，具體請參考相關資料。
軟件架構：
采用ASP.Net+IIS+SQLSERVER 三層結構，或者說表現層+業務邏輯層+數據訪問層的三層結構，其中業務邏輯層又可以在拆分處多個層次，從而整個系統成為一個“多層結構”模式。在業務層和數據訪問層又可以采用緩存技術等。
硬件架構：
l 多Web服務器負載均衡
l 多DNS解析
l 服務器集群
l 多層防火牆
一般的企業網站出於自身資金的原因很難用到上面的全部技術/結構，但是處於一般的性能和安全考慮，至少采用下面的硬件架構：
一台Web服務器+ 一台數據庫服務器+一個硬件防火牆，其中數據庫服務器最好能有第二層防火牆並且不用TCP/IP和Web服務器直接連接。Web服務器內存至少1G以上，數據庫服務器內存2G以上，每個服務器最好能夠有2個以上的CPU。
