国产视频一二三四区_国产伦视频一区二区三区_五月天久久狠狠_欧美一区二区三区日韩_97在线观看免费高_欧美成人在线免费视频_美女久久网站_中国女人做爰视频_国产精品久久久久久久浪潮网站_乱熟女高潮一区二区在线_国产一区二区在线影院_91超碰在线免费观看

在正式動手開發網站之前，首先應當對將要開發的網站進行認真規劃和設計，弄清楚自己想要的網站是個什么樣子，這很重要。一般來講，網站規劃設計包括網站功能、物理部署、期望性能、架構分層等幾個方面。

3.1　功能規劃

網站要實現的功能視商業目的、用戶需求而定，在正式開始開發之前一定先要規劃好網站的功能，只有在事先規劃好功能，才能夠在開發中少走彎路，快速地將網站交付。

首先，根據功能需求確定采用B/S網站開發的架構是否合適。現在有很多公司和客戶盲目追趕所謂的"B/S"大潮，認為一切應用都可以且應該使用B/S架構來實現，實際上這是極不明智的行為。

一般來講，只有在如下情況下才有使用B/S的必要：

（1）系統安全性要求不是非常高，從某種意義上來講是公開的。換句話說就是這個應用是可以讓大家都知道的，包括系統的和非合法用戶。但是如果不是這樣，那么就不要使用B/S架構，比如企業內部使用的進銷存管理系統。

（2）目標用戶群體是開放的或公開的，并不限定于少數已知且確定的人群。

（3）不需要離線使用的應用程序。

在確定使用網站的方式來呈現系統之后，我們需要對系統功能進行進一步的分析，一般要考慮如下幾點：

（1）功能的單一性和關聯性。簡單地說就是“高內聚，低耦合”，一個網站所實現的功能盡量單一或者多個功能之間具有關聯性，否則請考慮開發成多個網站。

（2）用戶的單一性。網站的用戶群體也應當盡量單一。

（3）后臺管理的開放性。一般來講這里要考慮的是網站的后臺管理部分是否也使用B/S架構來開發，比如一個典型的電子商務網站，那么后臺的訂單管理、配送管理等功能是不適合使用B/S架構的。

3.2　部署規劃

在設計完功能，充分了解需求之后，就應當考慮系統將來的部署問題，這個時候應當對目標用戶群做一個調查，了解用戶的使用情況，比如一般都多少人同時在線，通常采用什么方式上網，哪些功能用得比較多，等等。然后根據這些調查數據進行部署規劃。

1.部署到局域網還是因特網　是部署到局域網還是因特網主要看使用人群以及使用地點，如果使用人群主要是企業內部員工，并且一般不會在家或者出差時登錄，則部署到局域網中會比較合適，相對來說安全得多，如果在某些情況下需要從外部訪問，可以考慮使用VPN。

2.如何解決網間互連問題　不知道這個問題算不算是中國特色。因為電信和網通間的互聯互通并不通暢，如果我們的系統部署在因特網上，那么就需要認真考慮如何解決這個問題，否則將來它可能會是個大麻煩。

解決辦法一般有3種：

（1）使用兩臺服務器，分別部署在電信和網通的機房里，然后電信和網通的用戶分別訪問各自的服務器，這種方法是基本的解決方案，但是兩臺服務器間的數據同步將會是一件讓人比較頭疼的事情。

（2）使用一臺服務器，部署在電信或者網通某個服務商的機房里，然后找一家鏡像站點公司，這樣的鏡像站點公司會有很多的服務器，分布在全國各地，和他們簽約后，他們的鏡像服務器會定時到你的服務器上抓取靜態頁面并儲存起來，這樣各地的用戶訪問你的網站的時候，實際上是訪問在他們本地的鏡像服務器的內容，這種方式對于訪問速度的改善為明顯，因為已經不僅僅解決了網間互聯的問題，實際上每個用戶訪問的都是本地的（比如說是本市或本省的）服務器。但這種方案的缺陷是它只比較適合于主要是靜態內容的網站，對于我們使用ASP.NET技術構建的動態站點來說并不合適。

（3）使用一臺服務器，裝上兩塊網卡，找一個同時有電信和網通兩個出口的主機托管服務商，兩塊網卡分別接到電信和網通兩個出口上，然后電信和網通的用戶分別通過各自的出口訪問同一臺服務器。這是相對來說比較完美的解決方案，只是需要找這樣一家能夠同時提供兩個不同的網絡出口的主機托管服務商不是一件很容易的事情。青島網站建設視覺導向性

3.3　性能規劃

在性能方面的規劃也要在前面所做的對用戶進行的訪問調查的基礎上進行，根據用戶數及并發訪問量等數據來進行考慮。

3.3.1　升級服務器還是采用多服務器

在需要提高網站性能的時候，一般有兩種方案可以考慮，一種是升級服務器，另外一種是采用多服務器部署。

升級服務器，換用更高頻率或者多核CPU、增加內存，可以提高單服務器性能，加快相應速度，但畢竟可升級的空間是有限的，盡管能夠縮短一些頁面響應時間，但是并不能夠很好地應對訪問請求量增大的情況。

采用多服務器部署，將網站從單純的邏輯分層變為物理分層，比如將數據庫、業務邏輯和Web站點分別部署到單獨的服務器上，甚至進一步將每一層應用

都分別平行分布到多臺服務器上。采用這種方式可以有效應對訪問量增大的情況，但是由于產生了服務器間的通信數據量，對于單個請求來講，響應時間不會得到縮短，反而還有可能延長。而且采用多服務器部署的方式，對系統的開發也會產生影響，如果系統分層的層間通信是采用緊耦合的方式，那么就無法分布到多臺服務器上，然后在多服務器部署的情況下還要考慮Session的儲存，以及服務器間采用何種方式通信等問題。

3.3.2　多服務器間通信的性能考慮

如果確定采用多服務器的部署模式，那么就要認真考慮多服務器間通信所存在的性能問題及其解決辦法。

首先，參與分布式計算的成員服務器之間好采用高速局域網連接，如果因服務器分布于不同地點而無法放置于同一局域網內，那么也應當使用高速專線相連，這不僅是基于性能的考慮，同時也是基于安全的考慮。

其次，服務器間數據傳輸應當遵守“低頻率、粗粒度”的原則，服務器間連接的次數應當盡量低，每次連接傳輸的數據應當盡量多一些。因為服務器間數據傳輸的速率畢竟始終無法與訪問內存或硬盤的速率相比，而且建立連接、管理連接也是需要消耗時間成本的，所以相比從其他服務器獲取數據，更應當優先考慮從本地內存或硬盤中讀取數據，而如果將總的連接時間（包括建立連接、傳輸數據、關閉連接）視為分母，傳輸有效數據的時間視為分子，那么很顯然這個比值應當盡可能地接近于1才是比較理想的。當然，傳輸的總數據量也不能太大，必須使總的連接時

間保持在可接受的范圍內。

再次，應當考慮服務器間的連接技術。例如，使用Web Services和.NET Remoting連接，其性能是大不一樣的。如果相互連接的兩臺服務器是采用的不同技術開發的，那么使用Web Services互聯是比較好的連接方式，但是效率較低；如果相互連接的兩臺服務器都是采用.NET技術開發的，那么近期推薦采用.NET Remoting互聯，遠期則推薦使用Windows Communication Foundation互聯，這樣效率比較高，而且開發簡便、功能強大。

后，必須考慮建立服務器緩存。對于多服務器連接的系統，在某些服務器上建立數據緩存是必要的，這樣可以有效地減少服務器建立數據連接的次數，從而提高響應速度。但是在哪些服務器上建立緩存，建立什么樣的緩存，則是需要仔細考慮的。以典型的數據庫服務器、業務處理服務器、網站服務器的三服務器應用模式為例，業務處理服務器上應當建立數據緩存，對數據庫中的常用數據進行緩存；而在網站服務器上，則只適合建立對于靜態頁面的頁面緩存。

3.4　網站架構分層設計

對網站系統進行分層是必要的，這不僅僅是因為需要對網站進行物理分層，即部署到多臺服務器上，還因為：

（1）充分發揮開發人員特長。因為人無完人，并不是每個人都是全能選手，有些人只精通C#，有些人卻只喜歡T-SQL，還有專業美工人員，等等，如果將

不同類型代碼混雜在一起進行開發，將無法發揮每個工作人員的特長。

（2）增強代碼可讀性。其實這一點和上一點相類似，只不過關注點從寫變成了讀。同時還因為將功能區隔開來，每個文件只關心一個功能點，這樣進一步提高了源碼的可讀性。

（3）實現代碼重用。很明顯網站系統中有很多可以重用的模塊，比如數據訪問、數據緩存、身份認證以及權限控制，這些模塊都可以也應當提取出來進行重用，從而大量減輕工作量和縮短開發時間。

（4）易于擴展。網站系統在使用過程中可能會根據需要進行擴展，例如增加或修改功能，部署到更多的服務器上等，那么在設計開發的時候就需要考慮到這種情況，分層開發也是為了應對這種情況的出現。在定義好接口之后，當系統進行擴展時，只要新開發的模塊符合接口規范，那么原有代碼只需要進行很小的修改甚至不需要修改，就可以方便地加入新的模塊或替換掉舊的模塊。

（5）易于分布式部署。邏輯分層是物理分層的前提，只有進行了邏輯分層，并考慮了層與層之間的服務器傳輸，才能將其分布到多臺服務器上。3.4.1　系統分層圖

網站系統分成多少層，分為哪些層，并沒有一個統一的定論，根據經驗和需要，每個系統架構師都會有不同的理解。筆者根據自己近年來做.NET B/S系統開發和架構的經驗，以系統能夠方便地分布到三臺服務器上，并且能夠方便地進一步擴

展為目標。

3.4.2　數據定義層

數據定義層將為從數據訪問層到界面層的所有層次使用，這一層用于定義數據結構，比如強類型數據集，或純粹描述數據的類、結構以及枚舉。

基于數據與行為分離的原則，這一層只包含對數據結構的定義，而不包含對數據的操作。

3.4.3　數據訪問層

數據訪問層執行從數據庫（或其他數據服務）獲取數據或向數據庫發送數據的功能。在分布式應用程序結構中，相應功能使用ADO.NET數據適配器和SQL服務器存儲過程來完成：

（1）從“業務規則”層接收請求，從“數據服務”獲取數據或向其發送數據。

（2）使用存儲過程獲取數據，并可選用ADO.NET向數據庫發送數據。

（3）以強類型的ADO.NET數據集的方式，將數據庫查詢結果返回到“業務規則”層。

數據訪問層如果設計得足夠合理，將具有高度的靈活性：高度可復用、高度可擴展，并且在數據源類型改變時無需修改程序。在第5章中我們將進行詳細闡述。

3.4.4　數據緩存層

數據緩存層的存在旨在減少對數據庫的訪問次數，以提高性能。數據對于大多

數系統來說是核心，大部分的操作都是對數據的訪問操作，包括查詢、讀取和新增修改刪除。每一次對數據庫的查詢都是寶貴的，不能只使用一次就馬上丟棄。尤其在遵循“低頻度、粗粒度”的服務器間連接原則的系統上，每一次對數據庫的訪問都讀取了大量的數據，但這大量的數據在頁面上顯示的時候，可能只顯示了其中很小的一部分，如果在顯示了這小小的一部分之后就馬上丟棄的話，粗粒度原則也就沒有任何意義了。所以需要在每次查詢數據庫之后，將查詢結果緩存起來，留待下次使用。

那么隨之帶來的問題就是：服務器的內存大小畢竟是有限的，在數據被緩存之后，總要在合適的時候釋放，怎樣設計這樣的一套釋放機制才是合理的；當對數據庫進行新增、修改、刪除操作之后，數據緩存中的數據和數據庫中的數據需要進行同步，才能保證顯示數據和實際數據一致，該怎樣進行同步才能夠保證其可靠性；更為復雜的是，如果在部署中存在多臺業務邏輯服務器，而每臺業務邏輯服務器都配置了數據緩存，那么該通過怎樣的一個機制來保證多臺服務器中的數據都是一致的。關于這些問題，我們將在第6章進行描述。

另外，為了保證數據訪問的靈活性，好能夠使數據訪問層和數據緩存層實現相同的接口。

3.4.5　業務邏輯層

業務邏輯層包含業務對象本身以及應用于它們的規則。這也是主要業務對象所在的位置。它們實現業務實體或系統對象。系統的業務規則將在這些對象中編

碼，盡管部分業務規則可能實際上已在數據庫的存儲過程和觸發器中進行了編碼。

業務邏輯層的作用是：

·從“業務界面”層接受請求。

·根據編碼的業務規則處理請求。

·使用“數據訪問”層從“數據服務”層獲取數據，或將數據發送到“數據服務”層。

·將處理結果傳遞回“業務界面”層。

3.4.6　業務界面層

業務界面層常用于向基礎業務對象提供一致的接口，并將客戶端同基礎業務邏輯的更改隔離開。當它出現時，其或者處于客戶端和業務邏輯之間，或者處于Web服務層和業務邏輯層之間。

在本系統架構中，業務界面層分為兩層，用于跨服務器的數據傳輸，這樣設計的目的是，在根據需要改變數據傳輸方式時，在保證接口不變的前提下，只需要對這兩層進行替換即可，而不需要修改業務邏輯層或界面層的代碼。

業務界面層的作用是：

·從“界面”層（Web用戶界面客戶端應用程序）接收用戶輸入。

·如果請求需要對數據進行只讀訪問，則可能使用“數據訪問”層。

·將請求傳遞到“業務規則”層。

·將響應從“業務規則”層返回到“界面”層（Web用戶界面客戶端應用程序）。

在技術上，根據需要的不同，目前推薦使用.NET Remoting或Web Services：如果考慮需要與采用其他技術的系統進行數據交換，比如采用JSP技術的青島網站制作或其他公司采用Java等其他技術開發的系統，則推薦使用Web Services，這樣保證了比較好的兼容性，只是效率相對較低；如果只是與同樣采用.NET技術的系統相連接，那么推薦使用.NET Remoting，這樣效率較高。而遠期則推薦使用Windows Communication Foundation技術。

同時，為了保證代碼調用的靈活性，業務界面層Client和業務邏輯層好能夠實現相同的接口。

3.4.7　界面層

界面層是指在應用程序中實現的客戶端。在分布式應用程序結構中，用戶服務可以是Web客戶端或Windows客戶端，或者兩者都是，或者兩者都不是，這具體

取決于特定的應用程序。這里，特定于Web客戶端。

界面層起的作用是：

·管理Web頁的呈現和行為。

·顯示數據。

·捕獲數據。

·數據驗證檢查。

·為用戶提供任務指南。

·向“業務外觀”發送用戶輸入。

·從“業務外觀”接收結果。

·向用戶顯示錯誤。

對于Web界面層的開發技術將是本書的重點，我們將在后面進行詳細論述。