PP团队圣经巨著《Application Architecture Guide2.0》24章-Web程式开发向导
?
第二十四章? Web程式原型
目標
l???????? 學習Web程式的通常設計考慮點。
l???????? 學習Web程式的主要原則。
l???????? 學習Web程式的層指導原則。
l???????? 學習性能，安全以及部署指導原則。
?
概覽
Web程式的核心是服務器端的邏輯。它可能由很多不同的層組成。典型的例子就是三層架構，表現層，業務層以及數據層。下面的圖表列舉了通用的Web應用架構，由一些不同領域的通用組件組成。
?
?
設計考慮
設計安全和高性能的Web應用的主要目標是將任務分解成不同的關注點以減少復雜性。設計時請考慮以下原則：
l???????? 把應用邏輯分區。將應用邏輯分為表現層，業務層和數據層。這將提高代碼可維護性以及允許監控和優化每一層的性能。一個清晰的分層可以提供程式更好的擴展性。
l???????? 在層間使用抽象來實現松耦合。如同輸入和輸出Facade可以將請求轉換成層組件理解的格式。而且，你可以使用接口類型或抽象基類來定義共享的抽象，以被接口組件實現。
l???????? 明確組件之間如何通信。這要求你首先要了解程式所支持的部署環境。你必須確定通信是要跨越物理邊界，進程邊界還是所有組件都在同一個進程中。
l???????? 減少數據包往返。當設計Web程式，考慮使用緩存，輸出緩沖來減少瀏覽器和服務器，Web服務器和下載服務器之間的數據包往返。
l???????? 考慮使用緩存。一個好的緩存策略也許是與性能關系最大的設計考慮點。Asp.net的緩存包括輸出緩存，局部頁緩存以及緩存API，設計時請好好利用這些優勢。
l???????? 考慮使用日志和監控組件。你必須審核和記錄穿越程式層之間的活動。這些日志可以用來檢測可疑的活動，通常可以在早期發現對系統的攻擊行為。
l???????? 避免長時間運行的任務鎖。如果你有長時間運行或加鎖的操作，考慮使用異步的方法以允許Web服務器處理其它輸入請求。
l???????? 鑒別所有穿越信任邊界的用戶。比如，當從表現層訪問遠程的業務層時。
l???????? 不要在網絡間傳輸沒加密的敏感數據。如果你需要通過網絡傳遞密碼或授權cookie等敏感信息，考慮加密以及簽名數據或者使用SSL。
l???????? 使用最小權限賬戶來運行Web程式。如果攻擊者利用一個進程，而進程被限制訪問文件系統和其它系統資源，這樣會減少可能的損害。
?
Web程式結構
| Category
| Key Issues
|
| Authentication | 在信任邊界之間缺少驗證。 |
| ? | 在數據庫中使用普通文本格式來存儲密碼。 |
| ? | 設計自定義的驗證機制來代替內置的機制。 |
| Authorization | 在信任邊界間缺少授權。 |
| ? | 不正確的角色粒度。 |
| ? | 在不需要的時候使用代理。 |
| Caching | 緩存了易變的數據。 |
| ? | 沒有考慮緩存頁面輸出。 |
| ? | 緩存敏感數據。 |
| ? | 沒有緩存數據為ready-to-use格式。 |
| Exception Management | 對終端用戶暴露了敏感信息。 |
| ? | 沒有記錄異常的完整信息。 |
| ? | 用異常來處理應用程式邏輯。 |
| Logging and Instrumentation | 沒有在所有層實現適當的監控。 |
| ? | 沒有記錄嚴重系統事件和關鍵業務事件。 |
| ? | 不支持運行時的日志和監控配置。 |
| ? | 記錄了敏感信息。 |
| Navigation | 在用戶接口混合了導航邏輯。 |
| ? | 硬編碼視圖聯系。 |
| ? | 沒有核實用戶是否被授權訪問視圖。 |
| Page Layout(UI) | 對于復雜的布局使用基于表格的布局。 |
| ? | 設計了復雜的重載頁面。 |
| Page Rendering | 使用過多的回傳影響用戶體驗。 |
| ? | 使用過大的頁面降低了性能。 |
| Presentaion Entity | 在不需要的時候創建了自定義的實體對象。 |
| ? | 將業務邏輯添加到了表現層實體。 |
| Request Processing | 混合了處理邏輯和呈現邏輯。 |
| ? | 選擇了不適當的模式。 |
| Service Interface Layer | 破壞了服務接口。 |
| ? | 在服務接口里實現了業務規則。 |
| ? | 沒有考慮互操作性需求。 |
| Session Management | 使用了不正確的狀態存儲。 |
| ? | 沒有考慮串行化需求。 |
| ? | 在需要的時候沒有維護狀態。 |
| ? | 對大量數據如Dataset使用ViewState。 |
| Validation | 依賴客戶端驗證。 |
| ? | 在信任邊界間缺少驗證。 |
| ? | 沒有重用驗證邏輯。 |
?
?
驗證
不適當的或較弱的驗證可能會導致你的程式易受欺騙攻擊，字典攻擊，會話劫持以及其它類型的攻擊。
當設計驗證策略時，考慮以下原則：
l???????? 識別Web程式層之間的信任邊界。這將幫助你決定哪里需要驗證。
l???????? 使用平臺支持的驗證機制，如Windows驗證。
l???????? 如果你使用Forms驗證，盡可能利用平臺特性。
l???????? 如果你使用Forms驗證，保護你的授權cookie。
l???????? 如果你沒有使用SSL，考慮縮短session過期時間以降低授權cookie的暴露。
l???????? 在Web程式中將公共區和限制區分開。
l???????? 加強賬戶管理，如使用賬戶鎖定和過期。
l???????? 使用強密碼策略。包括特定的密碼程度和復雜度，以及密碼過期策略。
l???????? 不要在數據庫或數據源中存儲密碼，應該存儲hash加密過的密碼。
l???????? 保護信任的存儲區。
?
授權
不適當的或較弱的授權會導致信息暴露，數據被篡改以及權限被提升。深度防御是程式授權策略的關鍵安全原則。? 設計時考慮以下原則：
l???????? 識別Web層的信任邊界。
l???????? 對頁面和目錄訪問控件使用URL授權。
l???????? 使用Asp.net角色管理來進行角色授權。
l???????? 如果查找角色進程比較消耗資源，考慮緩存角色信息。
l???????? 考慮授權設置粒度。
l???????? 使用加密來保護授權過的cookie,或者設置HttpOnly屬性來防止客戶端腳本訪問。
l???????? 訪問下載資源時，用信任的子系統模型來實現身份識別。
l???????? 如果使用代理來指定特定的授權和訪問粒度，要考慮對性能和擴展性的影響。
?
緩存
緩存可以提高應用程式的性能和響應。但是，錯誤的緩存選擇和低劣的緩存設計可以降低性能和響應。你應該使用緩存來優化數據查找，避免網絡數據包往返，避免不必要和重復的處理。為實現緩存，你必須決定何時加載緩存數據。使用異步加載緩存或使用批處理可以避免客戶端延遲。
當設計緩存時，可以考慮以下原則：
l???????? 避免為每一個用戶緩存數據。
l???????? 緩存全局數據或者多用戶使用的數據。
l???????? 避免緩存易變數據。
l???????? 使用output緩存來緩存相對靜態的頁面。
l???????? 對頁面中的靜態用戶控件數據使用局部頁面緩存。
l???????? 選擇何時的緩存位置，如客戶端，代理服務器或Web服務器。
l???????? 貧困的共享資源是昂貴的，如網絡連接，可以使用緩存。
l???????? 緩存數據用ready-to-use格式。
l???????? 對于大量緩存，考慮用異步單線程加載或者使用批處理進程。
l???????? 考慮在表現層緩存要展示給用戶的數據。
l???????? 當數據不能有效的從數據庫檢索的時候，考慮在業務層緩存它。
l???????? 如果需要緩存大量的數據較長時間，那么將它緩存在數據庫里。
l???????? 避免使用分布式的聚合的緩存。
?
異常管理
設計有效的異常管理對于系統的安全性和可靠性非常重要。在Web頁面上正確的異常處理可以阻止將敏感的異常詳細信息展現給用戶，可以提高系統的穩固性以及避免系統不一致狀態的發生。
當設計異常管理策略時，考慮以下原則：
l???????? 不要用異常來控制邏輯流程，并且避免你的代碼發生異常。
l???????? 除非你處理它，否則不要捕獲異常。
l???????? 集中異常處理方案。
l???????? 對于不可料的錯誤使用全局的錯誤處理。
l???????? 對終端用戶使用友好的異常信息。
l???????? 不要在異常明細里顯示敏感信息。
l???????? 設計合適的異常傳播策略。
l???????? 設計合適的異常記錄策略。
l???????? 要記錄異常的詳細信息。
l???????? 設置異常管理系統以在錯誤發生的時候也要保證安全。
?
記錄和監控
l???????? 考慮使用平臺特性，如異常檢測來記錄和審核事件。
l???????? 集中設置日志和監控機制。
l???????? 考慮審核用戶管理的事件。
l???????? 審核不正常的活動。
l???????? 審核關鍵業務操作。
l???????? 創建安全日志文件管理策略。
l???????? 不要在日志或審核文件里存儲敏感信息。
?
導航
設計導航策略時，要把它與處理邏輯分開。它幫助用戶快速瀏覽網站，設計一致的導航結構可以降低系統的使用復雜性。
?
當設計導航策略時，考慮以下原則：
l???????? 使用眾所周知的模式，如MVC，可以將UI和復雜的導航邏輯解藕。
l???????? 考慮在MasterPage中封裝導航，這樣可以跨頁面保持一致性。
l???????? 在小的Web應用程式中，可以考慮將導航封裝于控件中。
l???????? 如果使用Menu,考慮使用.net的SiteMap Provider。
l???????? 設計SiteMap可以幫助用戶查找頁面，同時也允許搜索引擎抓取站點。
l???????? 如果在窗體間使用向導來實現導航。
l???????? 對于信息豐富且類似于樹狀管理的站點可以使用有層次的導航，如圖書館。
l???????? 使用可視的元素，如鏈接，導航菜單等以幫助用戶迅速的找到站點可用的東西。
l???????? 設計保存導航狀態策略。
?
頁面布局(UI)
設計程式時，要將頁面布局和特定的UI組件及UI處理過程分開。當選擇了一種布局策略，考慮是設計者還是開發者創建此布局。如果設計者創建此布局，那么選擇不需要編碼的布局方法或使用專門的開發工具。
?
當設計布局策略時，考慮以下原則：
l???????? 確定是否要支持跨瀏覽器。
l???????? 在任何可能的布局使用CSS。
l???????? 當你需要支持網格布局，那使用基于表格的布局，但是要牢記表格布局可能呈現較慢，而且不能完全的跨瀏覽器，并且在布局復雜的時候可能會有問題。
l???????? 如果你要在網格或以表格樣式來展現數據，那么使用HTML 表格來幫助弱視人群或其它特別的用戶。
l???????? 使用統一的布局可以盡可能的提供易用性。
l???????? 在ASP.NET里使用MasterPage為所有的頁面提供一個統一的視覺效果和感受。
l???????? 避免設計和開發大型頁面來完成多個功能，特別是通常一個請求只會調用很少的任務。
l???????? 分割頁面內容可以提高緩存效率和減少呈現。
?
頁面呈現
當設計頁面呈現時，要保證頁面呈現的效率和接口的最大利用。請遵循以下原則：
l???????? 盡量減少傳遞的頁面大小，例如，在不需要的地方Disable掉ViewState。
l???????? 考慮使用數據綁定選項。例如，可以為控件綁定自定義對象或DataSet。但是，數據綁定只能在ASP.NET里使用。
l???????? 使用AJAX來提高用戶體驗和獲取較好的響應。
l???????? 對大數據量使用分頁技術。
l???????? 設計全球化策略。如為字符串數據使用資源文件。
l???????? 考慮在用戶接口組件里設計本地化。
l???????? 將用戶處理組件從數據呈現和獲取程式里抽象出來。
?
表現實體(Presentation Entity)
在表現層里使用表現實體存儲數據以管理視圖表現實體不一定是必須的。只有當DataSet非常大或者復雜時，才使用表現實體將數據單獨從UI控件中分離出來存儲。設計或選擇合適的表現實體可以很容易的與UI控件進行綁定。
?
設計表現層實體時，考慮以下原則：
l???????? 決定你是否需要表現層實體。
l???????? 考慮使用自定義的類來將控件直接映射到業務實體。
l???????? 考慮表現層實體的串行化需求。
l???????? 避免將業務邏輯添加到表現實體中。
l???????? 考慮在表現實體中實現輸入數據驗證。
l???????? 考慮使用表現實體來存儲用戶接口狀態。
?
請求處理
當設計請求處理策略時，你要將請求處理邏輯從用戶接口分離出來，以分離每一個關注點。
?
當設計請求處理策略時，考慮以下原則：
l???????? 統一實現頁面請求處理前后邏輯以提高重用。例如，創建一個基類派生于Page類，并且包含了請求處理前后邏輯。
l???????? 考慮將UI處理分成三類，Model,View以及Controller/Presenter,通過使用MVC或MVP模式。
l???????? 為提高可測試性，避免在View和Model之間使用Passive View模式(MVP模式的一種)。
l???????? 如果你在設計需要處理大量數據的視圖，考慮View訪問Model時使用Supervising Contorller模式(MVP模式的一種)。
l???????? 如果程式不依賴于viewstate，而且也沒有很多控件事件，考慮使用MVC模式。
l???????? 如果包含復雜的導航和命令處理需求，考慮使用Front Controller模式(MVC的一種)。
l???????? 不要在視圖中實現請求處理。
l???????? 在合適的地方使用過濾器模式來實現可拆卸的過濾器。
l???????? 考慮使用事件來通知調用者更改狀態數據。例如，使用觀察者模式。
l???????? 確保在請求處理邏輯中沒有混合業務規則。
?
會話管理
當設計Web程式時，一個有效的和安全的Session管理策略對于性能和可靠性非常重要。你要考慮Session管理的一些因素，如存放什么，存放位置以及信息保存時間。
?
當設計Session管理策略時，考慮以下原則：
l???????? 不要依賴客戶端狀態管理。
l???????? 選擇合適的會話狀態存儲，如進程，Asp.net StateServer,或者SQLServer。
l???????? 如果你有一個Web服務器，需要最適宜的會話性能以及并發會話相對較少，可以使用在進程內存儲會話狀態。
l???????? 如果你的Session重建代價非常昂貴，并且在Asp.net重啟的時候還會保持，那么在本地的WebServer上使用會話狀態服務。
l???????? 如果你首先考慮的是可靠性，那么將會話存儲在SQLServer中。
l???????? 對于Web farm可以使用遠程的會話狀態服務或Sqlserver狀態存儲。
l???????? 保護你的會話狀態通信渠道。
l???????? 限制訪問會話狀態數據。
l???????? 對于會話數據使用基本類型以減少串行化花費。
l???????? 使用平臺特性來加密Cookie中的Session ID。
l???????? 如果客戶端瀏覽器禁用cookies,使用無cookie的Session。
?
驗證
設計一個有效的驗證方案對于程式的安全性和可靠性非常重要，請遵循以下原則：
l???????? 識別Web程式層之間的信任邊界，并且驗證所有穿越邊界的數據。
l???????? 假定所有客戶端的數據都是惡意的。
l???????? 設計驗證策略以限制，拒絕和清除所有惡意的數據。
l???????? 驗證輸入長度，范圍，格式和類型。
l???????? 驗證所有輸入，如查詢字符串，Cookie和Html控件。
l???????? 不要只依賴Asp.net 請求驗證。
l???????? 考慮使用Asp.net 驗證控件。
l???????? 在Asp.net中使用正則表達式來限制輸入。
l???????? 不要顯示不信任的輸入。
l???????? 如果需要輸出不信任的數據，用HTML編碼輸出。
l???????? 為提高用戶體驗使用客戶端驗證，以及在服務器端再次驗證以提高安全。
l???????? 避免用戶輸入文件路徑和名稱。
?
表示層考量
Web程式的表現層提供了用戶接口和用戶交互。設計必須集中于分離關注點，將用戶交互邏輯和用戶接口組件解藕。
?
當設計表現層時，考慮以下原則：
l???????? 考慮將用戶接口組件和用戶接口處理組件分離。
l???????? 評估表現層和業務及數據層的交互方式。
l???????? 對于客戶端和服務器端都使用輸入驗證策略。
l???????? 設計數據格式和顯示策略，包括對用戶的視覺樣式。
l???????? 使用頁面輸出緩存換局部緩存來緩存靜態頁或頁面的一部分。
l???????? 使用觀察者模式來處理用戶事件。
l???????? 使用Page Controller模式將業務層和表現層分離。
l???????? 當你有復雜的頁面導航邏輯并且需要動態配置時，使用Front Controller模式。
l???????? 如果需要將控件編譯進程序集以重用，或你需要對現存的服務器控件添加額外特征，使用Web服務器控件。
l???????? 如果需要重用一些頁面的局部UI或需要緩存頁面的特定部分，使用Web用戶自定義控件。
?
業務層考量
當設計Web程式的業務層時，考慮怎樣實現業務邏輯和長時間運行的工作流。設計業務實體代表真實世界數據，以及使用它來在組件間傳遞數據。
?
當設計業務層時，考慮以下原則：
l???????? 設計一個單獨的業務層來實現業務邏輯和工作流。這將提高程式的可維護性和可測試性。
l???????? 考慮集中和重用通用業務邏輯功能。
l???????? 設計無狀態的業務層。這將幫助減少資源爭奪及提高性能。
l???????? 對于業務實體使用粗粒度的包，如DTO。
l???????? 業務組件要高內聚，低耦合。
l???????? 對重要的業務操作使用事務。
l???????? 決定同步或異步執行業務流中的處理步驟。
?
數據層考量
為Web程式設計一個抽現訪問數據庫的數據層。使用單獨的數據層將使程式容易配置和維護。可以使用服務代理來使數據層訪問外部服務。
?
當設計數據層時，考慮以下原則：
l???????? 設計一個單獨的數據層以隱藏數據庫的詳細信息。
l???????? 使用實體對象在層間傳輸數據和交互。
l???????? 對不同類型的數據存儲選擇合適的數據訪問技術。
l???????? 利用連接池來減少打開的連接數量。
l???????? 設計異常處理策略來處理數據訪問錯誤，并且將異常拋轉到業務層。
l???????? 考慮使用批處理操作來減少數據庫的數據包往返。
?
服務層考量
如果你計劃遠程部署業務層或者使用Web Service來暴露業務邏輯，考慮使用單獨的服務層。
?
當設計服務層時，考慮以下原則：
l???????? 設計粗粒度的服務方法以減少客戶端和服務器的交互，以及提供松耦合。
l???????? 不要認為只有一種客戶端來訪問服務。
?
?
性能考量
在Web程式的早期設計階段，通過獲取非功能的需求來識別性能對象。響應時間，吞吐量，CPU,內存以及磁盤IO是必須考慮的關鍵因素。
注意以下原則：
l???????? 保證性能需求是特定的，現實的和靈活的。
l???????? 使用非分布式部署來提高性能。
l???????? 實現緩存技術以提高程式性能和擴展。
l???????? 執行批處理操作來減少邊界的數據包往返。
l???????? 避免在表現層進行原子事務操作，這會降低可擴展性。
l???????? 在進程里存儲會話信息。
l???????? 減少在服務器和客戶端之間傳輸的HTML數據。
l???????? 避免不必要的網絡數據包往返。
?
安全考量
安全對于保證數據的一致性和機密性非常重要。你需要為Web程式設計一個安全策略，使用已測試和證明的安全解決方案，以及實現審核，授權和數據驗證，以保護系統免受威脅。
?
考慮以下原則：
l???????? 在任何的信任邊界使用審核。
l???????? 考慮使用強大的授權機制以限制資源訪問和保護業務邏輯。
l???????? 考慮使用輸入和數據驗證以防止跨站腳本攻擊和代碼注入等安全威脅。
l???????? 不要依賴客戶端驗證。
l???????? 考慮加密和簽名任何通過網絡的敏感數據。
?
部署考量
當部署Web程式時，你需要考慮層和組件的位置對性能，擴展和安全的影響，另外也要設計取舍。使用分布式或非分布式的部署取決于業務需求和Infrastructure限制。
?
部署時考慮以下原則：
l???????? 考慮使用非分布式部署來提高性能。
l???????? 考慮使用分布部署來實現可擴展性和提高每層的安全性。
?
非分布式部署
在非分布式部署的環境里，Web程式的各個邏輯層都放置在相同的Web服務器上，除了數據庫。你必須考慮程式怎樣處理多個并發用戶，以及怎樣保證在同個Server上其它層的安全。
?
考慮以下原則：
l???????? 如果你不需要和其它程式共享業務邏輯考慮使用非分布式的部署。
l???????? 如果Web程式對性能要求較高，可以使用非分布式的部署，因為從本地調用其它層會提供額外的負擔。
l???????? 為你的業務層使用基于組件的接口。
l???????? 如果你的業務邏輯運行在同一個進程里，避免在業務層審核。
l???????? 考慮使用可信任的身份來訪問數據庫（通過信任的子系統Model）。這可以提高性能和系統可擴展性。
l???????? 考慮加密以及數字簽名Web服務器和數據庫間傳遞的敏感數據。
?
分布式部署
在分布式部署環境里，Web程式的表示層和業務層邏輯在單獨的物理層，并且需要遠程通信。通常需要把業務和數據訪問層放置于同一服務器。
?
當選擇分布式部署時，考慮以下原則：
l???????? 除非需要否則不要將業務邏輯組件單獨放置。
l???????? 如果你的業務邏輯被其它程式共享，考慮使用分布式部署。
l???????? 如果為了安全考量，禁止在前端Web服務器上部署業務邏輯的話，考慮使用分布式部署。
l???????? 在表現層和業務層之間使用防火墻以增加安全性。
l???????? 表現層不需要初始化，參與原子事務。
l???????? 為業務層使用基于消息的接口。
l???????? 使用TCP協議和業務層通信可以獲取更好的性能。
l???????? 在不同的物理層間保護敏感信息傳輸。
l???????? 如果業務層也被其它程式訪問，考慮在業務層使用審核。
?
負載平衡
當在多臺服務器上部署你的Web程式，你可以使用負載平衡來分派請求以保證它們可以被多個Web服務器處理。這將幫助提高響應，資源利用以及吞吐量。
如果設計Web程式使用負載平衡，考慮以下原則：
l???????? 設計可擴展的Web程式時避免太傾向于Server。請求從服務器發出，也被服務器處理。這種現象經常發生于你使用本地可更新的緩存，或者進程中或本地存儲會話狀態。
l???????? 考慮為Web程式設計無狀態的組件；例如，一個Web前段沒有進程狀態和有狀態的業務組件。
l???????? 考慮使用Windows網絡負載平衡(NLB)作為一個軟件方案來實現請求的重定向。
?
Web Farm考量
Web farm允許擴展程式，并且盡量減少硬件故障的沖擊。當你增加更多的服務器，你可以使用負載平衡或者集群方法。
?
考慮以下原則：
l???????? 考慮使用集群來減少硬件錯誤的影響。
l???????? 如果程式要求高輸入和輸出需求，考慮通過多數據庫服務器來分區數據庫。
l???????? 考慮配置Web farm來將同一個用戶的所有請求路由到同一個Server以提供親和性。
l???????? 當同一個用戶的請求不能保證被路由到同一個服務器時，在web farm不要使用進程內的會話管理。使用進程外的狀態服務器服務或數據庫服務器。
?
模式映射
| Category | Scenarios |
| Authentication and Authorization | Brokered Authentication |
| ? | Direct Authentication |
| ? | Federated Authentication (Single Sign On or SSO) |
| ? | Trusted Sub-System |
| Caching | Cache Dependency |
| ? | Page Cache |
| Exception Management | Exception Shielding |
| Logging and Instrumentation | Provider |
| Navigation | MVP |
| ? | MVC |
| Page Layout | Template View |
| ? | Composite View |
| ? | Transform View |
| ? | Two Step View |
| Request Processing | Page Controller |
| ? | Front Controller |
| ? | Passive View |
| ? | Supervising Controller |
?
關鍵模式
l???????? Composite View-將單個視圖合并為一個組合的表現層。
l???????? Exception Shielding –對外部系統或用戶過濾異常數據。
l???????? Front Controller – 將所有請求裝入管道以通過一個處理對象，它可以在運行時被裝飾者修改。
l???????? Modal View Controller – 將用戶接口和數據存放以及兩者間的代碼邏輯分離開來。
l???????? Modal View Presenter – 將用戶接口，數據存放以及代碼邏輯分離。
l???????? Page Cache – 使用頁面緩存來提高頻繁訪問的動態Web頁面（頁面不經常變化以及構建時消耗了系統的大量資源）的響應時間。
l???????? Page Controller – 將頁面的輸入請求，交給一個特定的頁面或Action來處理。
l???????? Template View – 實現一個通用的模板視圖，然后從它派生或創建視圖。
?
技術考量
基于微軟平臺，從Asp.net出發，你可以在Asp.net Web窗體中融合大量的技術，如Asp.net Ajax,Asp.net MVC,SilverLight,以及Asp.net Dynamic Data：
l???????? 如果通過Web瀏覽器來訪問Web程式，考慮使用asp.net web窗體。
l???????? 如果Web程式需要加強交互性或后臺處理，考慮使用Asp.net Ajax。
l???????? 如果Web程式包含富多媒體的內容和交互性，考慮使用SilverLight。
l???????? 如果Web程式需要實現以控制為中心的模型，將控制器分離以及提高可測試性，考慮使用Asp.net MVC。
l???????? 如果設計Web程式需要基于數據開發，考慮使用Asp.net Dynamic Data。
?
patterns & practices Solution Assets
? Web Client Software Factory at http://msdn.microsoft.com/en-us/library/bb264518.aspx.
? Building Secure ASP.NET Applications at http://msdn.microsoft.com/enus/
library/aa302415.aspx.
? Improving Web Application Security at http://msdn.microsoft.com/enus/
library/ms994921.aspx.
Additional Resources
? For more information on design patterns for Web applications, see Enterprise Solution
Patterns Using Microsoft .NET at http://msdn.microsoft.com/en-us/library/ms998469.aspx.
? For more information on designing and implementing Web client applications, see Design
and Implementation Guidelines for Web Clients at http://msdn.microsoft.com/enus/
library/ms978605.aspx.
? For more information on designing distributed Web applications, see Designing Distributed
Applications at http://msdn.microsoft.com/en-us/library/aa292470(VS.71).aspx.
? For more information on Web application performance issues, see Improving .NET
Application Performance and Scalability at http://msdn.microsoft.com/enus/
library/ms998530.aspx.
? For more information on Web application security, see Improving Web Application Security:
Threats and Countermeasures at http://msdn.microsoft.com/en-us/library/ms994921.aspx.
轉載于:https://www.cnblogs.com/niujunjie1/archive/2008/12/13/1354111.html
總結
以上是生活随笔為你收集整理的PP团队圣经巨著《Application Architecture Guide2.0》24章-Web程式开发向导的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： VC+MO2.0连接ArcSDE并且读出
- 下一篇： SharePoint Server 20