ASP.NET應用程序規劃與設計
文檔化用戶(hù)方案
用戶(hù)方案沒(méi)有什么令人驚異之處。通常，它們只是描述用戶(hù)如何與應用程序交互。用戶(hù)方案的關(guān)鍵價(jià)值在于記錄了關(guān)于每個(gè)人對用戶(hù)希望系統如何運行以及應用程序應如何響應的設想。通過(guò)完成這個(gè)過(guò)程，您將可以完全了解處理各種用戶(hù)與系統的交互時(shí)所需的數據點(diǎn)和函數。換句話(huà)說(shuō)，編寫(xiě)完善的用戶(hù)方案將有助于您確定完成解決方案需要實(shí)現的數據庫、中間件和用戶(hù)界面元素。
注意：Visual Studio .NET Enterprise Architect 有一項非常不錯的功能，即允許您使用 Microsoft Visio? 通過(guò) UML（統一建模語(yǔ)言）創(chuàng )建用戶(hù)方案，然后生成這些方案的基本代碼。在這里，我不打算深入探討這些細節，但是您可以在 MSDN? Academic Alliance 站點(diǎn)找到一篇關(guān)于這一主題的好文章 Generating .NET Code Using Visio Enterprise Architect‘s UML，作者是 Sreedhar Koganti。
有了上一節的目標聲明后，下面是 DotNetKB 項目的幾個(gè)示例用戶(hù)方案。
搜索知識庫
匿名用戶(hù)可以輸入一個(gè)或多個(gè)關(guān)鍵字并執行搜索，搜索將返回包含這些關(guān)鍵字的問(wèn)題和/或回答列表。用戶(hù)可以將關(guān)鍵字搜索鎖定在僅搜索問(wèn)題、僅搜索回答或者二者都搜索。返回的列表將顯示問(wèn)題及其回復數和被其他用戶(hù)訪(fǎng)問(wèn)的次數。單擊鏈接將返回以時(shí)間先后逆序排列的回復（純文本）列表。
將新問(wèn)題輸入到知識庫中
匿名用戶(hù)可以瀏覽用于向數據庫輸入新問(wèn)題以供授權專(zhuān)家審閱和回復的屏幕。用戶(hù)可以輸入問(wèn)題的標題和內容，并可以選擇在一系列主題中的某個(gè)主題下記錄該問(wèn)題。用戶(hù)還可以輸入他們的名字和相關(guān)的 URL（電子郵件、Web 地址等）。輸入將被驗證，以確保包含必需的數據并確保所有輸入數據不會(huì )受到腳本攻擊等。一旦數據經(jīng)過(guò)驗證并被保存到數據庫中，用戶(hù)將看到一個(gè)響應屏幕，感謝用戶(hù)的支持并將用戶(hù)直接連接到主頁(yè)。此外，用戶(hù)還可以選擇讓該站點(diǎn)“記住”他們的姓名和 URL 以備以后訪(fǎng)問(wèn)該站點(diǎn)時(shí)使用。
您已經(jīng)了解它的工作原理了，對嗎？每一個(gè)方案都嘗試細化用戶(hù)交互的重要方面。例如，上面列出的兩個(gè)方案表明用戶(hù)為“anonymous”（匿名用戶(hù)），這表示這類(lèi)用戶(hù)不需要登錄或進(jìn)行其他方式的授權。第二個(gè)示例還標識了若干輸入值、驗證步驟和可選操作。
當然，這只是兩個(gè)示例；完整的系統需要更多的方案。此外，需要特別注意的是，“用戶(hù)”不僅僅可以是人，也可以是您的程序需要與其通信的其他應用程序，甚至還可以是您的應用程序的其他部分。例如，一個(gè)方案描述主頁(yè)如何列出最近添加到知識庫中的內容，以供任何人查看。此例中的“用戶(hù)”將是主頁(yè)自身。還有一些方案描述專(zhuān)家如何查找和回復新問(wèn)題以及管理員如何更新主題列表并管理系統的其他部分。我已為討論這個(gè)簡(jiǎn)單的應用程序標識了 20 多種方案。您可以在 DotNetKB 中找到當前列表（以及與此項目相關(guān)的所有其他資料）。
至此我們就有了目標聲明和一些用戶(hù)方案?，F在，是時(shí)候稍憩一下，然后學(xué)學(xué)一些技術(shù)了。我們需要定義應用程序體系結構，這可以幫助我們以“鮮活有效的代碼”實(shí)際實(shí)現方案。
定義應用程序體系結構
有了基本的目的和為解決方案開(kāi)發(fā)的用戶(hù)方案列表后，您需要開(kāi)始籌劃整體的體系結構。主要目標是標識應用程序的邏輯方面和物理方面，即如何將應用程序拆分為各種有用的部分。在本節中還添加了安全性方面的內容。安全是在規劃的“一開(kāi)始”您就需要考慮的問(wèn)題，而不是在開(kāi)發(fā)周期中“最后添加”的內容。我們稍后會(huì )在本節中詳細討論這個(gè)問(wèn)題。
邏輯體系結構
從邏輯上講，您需要規劃解決方案以標識數據存儲、數據訪(fǎng)問(wèn)、業(yè)務(wù)規則、用戶(hù)界面等之間的“邊界”。通常，Web 開(kāi)發(fā)人員會(huì )選擇一個(gè)兩階段模型，并用 Web 窗體存儲用于訪(fǎng)問(wèn)現有數據存儲系統（例如 Microsoft SQL Server）的所有代碼。一個(gè)更有效的方法是創(chuàng )建一個(gè)位于 Web 窗體用戶(hù)界面與 SQL Server 數據存儲系統之間的中間層組件庫。這種三層方法（Web 窗體、組件、數據庫）通常是大多數應用程序所需的。但是，在某些情況下，可能需要一個(gè)其他層來(lái)處理服務(wù)器之間傳輸的數據。這個(gè)傳輸層可以使用獨立于平臺的協(xié)議（例如 XML-SOAP）來(lái)實(shí)現。但是，如果您從頭到尾都使用 Microsoft .NET 技術(shù)，則可以使用 .NET 遠程協(xié)議的二進(jìn)制版來(lái)完成這一任務(wù)，而且速度比使用 XML-SOAP 要快得多。
對于我們的示例，我們將定義三個(gè)邏輯邊界：用戶(hù)界面（Web 窗體）、中間層（一個(gè) .NET 組件程序集）和數據層（SQL Server 數據庫）。圖 1 顯示了如何表示這一內容。
圖 1：三層圖
現在我們有一個(gè)簡(jiǎn)單的邏輯模型。它是如何起作用的？它有助于我們考慮各個(gè)邏輯組之間的邊界。每個(gè)邏輯層應盡量與其他層獨立。理想的情況是，圖層中的更改應該對整體產(chǎn)生最小的影響。例如，如果將數據存儲從 SQL Server 更改到 XML 數據文件，唯一受到影響的圖層應是中間層圖層。用戶(hù)界面應該根本無(wú)需考慮更改。這會(huì )使您進(jìn)行思考：如何實(shí)現解決方案的實(shí)際編碼以實(shí)現此原則。
另外，邏輯層有助于我們考慮安全問(wèn)題。各個(gè)圖層之間的邊界都存在潛在的安全漏洞。而且，各個(gè)圖層可能有自己特定的安全措施（SQL Server 權限、.NET 運行時(shí)權限、ASP.NET 安全等）。同樣，我們稍后會(huì )在本節中詳細討論這個(gè)問(wèn)題。
文檔化用戶(hù)方案
用戶(hù)方案沒(méi)有什么令人驚異之處。通常，它們只是描述用戶(hù)如何與應用程序交互。用戶(hù)方案的關(guān)鍵價(jià)值在于記錄了關(guān)于每個(gè)人對用戶(hù)希望系統如何運行以及應用程序應如何響應的設想。通過(guò)完成這個(gè)過(guò)程，您將可以完全了解處理各種用戶(hù)與系統的交互時(shí)所需的數據點(diǎn)和函數。換句話(huà)說(shuō)，編寫(xiě)完善的用戶(hù)方案將有助于您確定完成解決方案需要實(shí)現的數據庫、中間件和用戶(hù)界面元素。
注意：Visual Studio .NET Enterprise Architect 有一項非常不錯的功能，即允許您使用 Microsoft Visio? 通過(guò) UML（統一建模語(yǔ)言）創(chuàng )建用戶(hù)方案，然后生成這些方案的基本代碼。在這里，我不打算深入探討這些細節，但是您可以在 MSDN? Academic Alliance 站點(diǎn)找到一篇關(guān)于這一主題的好文章 Generating .NET Code Using Visio Enterprise Architect‘s UML，作者是 Sreedhar Koganti。
有了上一節的目標聲明后，下面是 DotNetKB 項目的幾個(gè)示例用戶(hù)方案。
搜索知識庫
匿名用戶(hù)可以輸入一個(gè)或多個(gè)關(guān)鍵字并執行搜索，搜索將返回包含這些關(guān)鍵字的問(wèn)題和/或回答列表。用戶(hù)可以將關(guān)鍵字搜索鎖定在僅搜索問(wèn)題、僅搜索回答或者二者都搜索。返回的列表將顯示問(wèn)題及其回復數和被其他用戶(hù)訪(fǎng)問(wèn)的次數。單擊鏈接將返回以時(shí)間先后逆序排列的回復（純文本）列表。
將新問(wèn)題輸入到知識庫中
匿名用戶(hù)可以瀏覽用于向數據庫輸入新問(wèn)題以供授權專(zhuān)家審閱和回復的屏幕。用戶(hù)可以輸入問(wèn)題的標題和內容，并可以選擇在一系列主題中的某個(gè)主題下記錄該問(wèn)題。用戶(hù)還可以輸入他們的名字和相關(guān)的 URL（電子郵件、Web 地址等）。輸入將被驗證，以確保包含必需的數據并確保所有輸入數據不會(huì )受到腳本攻擊等。一旦數據經(jīng)過(guò)驗證并被保存到數據庫中，用戶(hù)將看到一個(gè)響應屏幕，感謝用戶(hù)的支持并將用戶(hù)直接連接到主頁(yè)。此外，用戶(hù)還可以選擇讓該站點(diǎn)“記住”他們的姓名和 URL 以備以后訪(fǎng)問(wèn)該站點(diǎn)時(shí)使用。
您已經(jīng)了解它的工作原理了，對嗎？每一個(gè)方案都嘗試細化用戶(hù)交互的重要方面。例如，上面列出的兩個(gè)方案表明用戶(hù)為“anonymous”（匿名用戶(hù)），這表示這類(lèi)用戶(hù)不需要登錄或進(jìn)行其他方式的授權。第二個(gè)示例還標識了若干輸入值、驗證步驟和可選操作。
當然，這只是兩個(gè)示例；完整的系統需要更多的方案。此外，需要特別注意的是，“用戶(hù)”不僅僅可以是人，也可以是您的程序需要與其通信的其他應用程序，甚至還可以是您的應用程序的其他部分。例如，一個(gè)方案描述主頁(yè)如何列出最近添加到知識庫中的內容，以供任何人查看。此例中的“用戶(hù)”將是主頁(yè)自身。還有一些方案描述專(zhuān)家如何查找和回復新問(wèn)題以及管理員如何更新主題列表并管理系統的其他部分。我已為討論這個(gè)簡(jiǎn)單的應用程序標識了 20 多種方案。您可以在 DotNetKB 中找到當前列表（以及與此項目相關(guān)的所有其他資料）。
至此我們就有了目標聲明和一些用戶(hù)方案?，F在，是時(shí)候稍憩一下，然后學(xué)學(xué)一些技術(shù)了。我們需要定義應用程序體系結構，這可以幫助我們以“鮮活有效的代碼”實(shí)際實(shí)現方案。
定義應用程序體系結構
有了基本的目的和為解決方案開(kāi)發(fā)的用戶(hù)方案列表后，您需要開(kāi)始籌劃整體的體系結構。主要目標是標識應用程序的邏輯方面和物理方面，即如何將應用程序拆分為各種有用的部分。在本節中還添加了安全性方面的內容。安全是在規劃的“一開(kāi)始”您就需要考慮的問(wèn)題，而不是在開(kāi)發(fā)周期中“最后添加”的內容。我們稍后會(huì )在本節中詳細討論這個(gè)問(wèn)題。
邏輯體系結構
從邏輯上講，您需要規劃解決方案以標識數據存儲、數據訪(fǎng)問(wèn)、業(yè)務(wù)規則、用戶(hù)界面等之間的“邊界”。通常，Web 開(kāi)發(fā)人員會(huì )選擇一個(gè)兩階段模型，并用 Web 窗體存儲用于訪(fǎng)問(wèn)現有數據存儲系統（例如 Microsoft SQL Server）的所有代碼。一個(gè)更有效的方法是創(chuàng )建一個(gè)位于 Web 窗體用戶(hù)界面與 SQL Server 數據存儲系統之間的中間層組件庫。這種三層方法（Web 窗體、組件、數據庫）通常是大多數應用程序所需的。但是，在某些情況下，可能需要一個(gè)其他層來(lái)處理服務(wù)器之間傳輸的數據。這個(gè)傳輸層可以使用獨立于平臺的協(xié)議（例如 XML-SOAP）來(lái)實(shí)現。但是，如果您從頭到尾都使用 Microsoft .NET 技術(shù)，則可以使用 .NET 遠程協(xié)議的二進(jìn)制版來(lái)完成這一任務(wù)，而且速度比使用 XML-SOAP 要快得多。
對于我們的示例，我們將定義三個(gè)邏輯邊界：用戶(hù)界面（Web 窗體）、中間層（一個(gè) .NET 組件程序集）和數據層（SQL Server 數據庫）。圖 1 顯示了如何表示這一內容。
圖 1：三層圖
現在我們有一個(gè)簡(jiǎn)單的邏輯模型。它是如何起作用的？它有助于我們考慮各個(gè)邏輯組之間的邊界。每個(gè)邏輯層應盡量與其他層獨立。理想的情況是，圖層中的更改應該對整體產(chǎn)生最小的影響。例如，如果將數據存儲從 SQL Server 更改到 XML 數據文件，唯一受到影響的圖層應是中間層圖層。用戶(hù)界面應該根本無(wú)需考慮更改。這會(huì )使您進(jìn)行思考：如何實(shí)現解決方案的實(shí)際編碼以實(shí)現此原則。
另外，邏輯層有助于我們考慮安全問(wèn)題。各個(gè)圖層之間的邊界都存在潛在的安全漏洞。而且，各個(gè)圖層可能有自己特定的安全措施（SQL Server 權限、.NET 運行時(shí)權限、ASP.NET 安全等）。同樣，我們稍后會(huì )在本節中詳細討論這個(gè)問(wèn)題。
物理體系結構
確定邏輯層后，考慮物理層也很重要。例如，您可以在同時(shí)安裝有 SQL Server、Internet Information Server、ASP.NET 和 .NET 運行時(shí)的單個(gè)實(shí)際計算機上實(shí)現這個(gè)應用程序。這將是一個(gè)物理層。但更可靠且可擴展的方法是：在由三個(gè) Web 服務(wù)器組成的簇上部署 Web 窗體，在兩個(gè)應用服務(wù)器上部署 .NET 組件程序集，在兩個(gè)故障恢復模式的 SQL Server 上部署數據庫。這樣產(chǎn)生的物理體系結構將七個(gè) Windows 服務(wù)器包含在三個(gè)主要組中：Web 簇、組件簇和數據庫簇。如果您了解系統的不同邏輯部件可以位于不同的計算機上，您可能會(huì )實(shí)現不同的代碼。
對于我們的示例，我們采用一個(gè)有效且強大的兩層模型：Web 服務(wù)器托管用戶(hù)界面和組件，數據庫服務(wù)器托管 SQL Server 數據存儲。如果通信量非常大，這個(gè)模型使我們可以靈活地在簇中添加更多的服務(wù)器，并使其保持足夠的簡(jiǎn)潔以便于處理。下面的圖像顯示了此物理體系結構與前面定義的邏輯體系結構之間的映射關(guān)系。
圖 2：物理體系結構與三層體系結構之間的映射關(guān)系
正如您看到的那樣，邏輯體系結構和物理體系結構不必相同。在規劃階段還要考慮一項內容：安全。
安全規劃
Microsoft 有一個(gè)關(guān)于安全性與軟件這一主題的歌訣：“Secure by design, secure by default, and secure by deployment（設計安全，默認安全和部署安全）”。即，在安全中設計，期待系統在默認情況下是安全的，以及創(chuàng )建可以在安全環(huán)境中成功部署的解決方案。安全始終是重要的。既然越來(lái)越多的軟件要在公用的 Internet 上“生存”，編寫(xiě)安全的軟件就更加關(guān)鍵。對于我們而言，幸運的是，.NET 運行時(shí)和 Windows 操作系統提供廣泛的安全選項和功能，我們可以輕松地將其包含在我們的應用程序中。無(wú)需過(guò)分注重標識和消除聯(lián)機解決方案中安全漏洞的細節，我們可以指出其中一些最常見(jiàn)的漏洞并指出我們的應用程序規劃如何進(jìn)行處理。
注意：有關(guān)可用選項的詳細信息，請參閱 Microsoft Security Developer Center。
緩沖區溢出
這可能是已編譯應用程序中最常見(jiàn)的安全漏洞。由于我們將使用 .NET 運行時(shí)，而它是設計用來(lái)在內存中安全運行的，因此不太可能發(fā)生緩沖區溢出。此外，我們使用 Microsoft Visual Basic? .NET 對解決方案進(jìn)行編碼，而 Microsoft Visual Basic? .NET 不像 C 或 C++ 那樣容易受到緩沖區溢出問(wèn)題的影響。但是，即使我們打算用 C++ 創(chuàng )建組件，我們還可以使用編譯程序的特殊功能，GS 轉換，來(lái)保護我們免受大多數緩沖區溢出的攻擊。
數據庫攻擊
另一種常見(jiàn)的安全漏洞可能會(huì )使惡意用戶(hù)獲得訪(fǎng)問(wèn)存儲在數據庫中的原始數據的權限。為了防止黑客獲得數據的控制權，我們僅使用 SQL Server 存儲過(guò)程，而不使用“內聯(lián)查詢(xún)”。這樣可以大大減少試圖在輸入流中插入其他 SQL 命令的攻擊。我們還在程序中多個(gè)位置處使用輸入驗證，以確保所有輸入僅包含有效的字符。
交叉站點(diǎn)腳本攻擊
對 Web 應用程序進(jìn)行的常見(jiàn)攻擊還有一種，它涉及到用戶(hù)在輸入流中添加客戶(hù)方腳本，這類(lèi)攻擊將執行附加的對話(huà)并誘騙用戶(hù)將個(gè)人數據發(fā)送到黑客自己的 Web 站點(diǎn)。要解決這個(gè)問(wèn)題，我們使用 ASP.NET 1.1 的一個(gè)新功能，過(guò)濾出這種惡意代碼的所有輸入，防止將它置入系統中。顯示屏幕上還包含附加代碼，它將自動(dòng)禁用任何腳本或顯示可能會(huì )插入到數據存儲中的標記。
至此，我們已獲得了應用程序的邏輯模型和物理模型，以及確保實(shí)現方案包含的安全功能清單。擁有了這些以及目標聲明和用戶(hù)方案，我們可以開(kāi)始這次“編碼前”探險的最后一部分了。
完成設計文檔
在直接進(jìn)入項目的編碼部分之前，需要花一點(diǎn)時(shí)間實(shí)際勾畫(huà)出應用程序的邏輯組件，這非常重要。在我們的示例解決方案中，我們要實(shí)現解決方案的三個(gè)邏輯組件：數據庫、.NET 數據訪(fǎng)問(wèn)組件和 ASP.NET 用戶(hù)界面。在下面幾篇文章中，我們將非常詳細地介紹如何實(shí)現這些組件。但現在，我們只是勾畫(huà)出每個(gè)組件的大致輪廓，討論過(guò)程中最重要的方面，即文檔化組件間的交互。
數據庫
對于 DotNetKB 應用程序，我們需要將數據存儲在三張表中：主題、問(wèn)題和回答（請參閱下圖）。
圖 3：主題、問(wèn)題和回答表
我們需要使用存儲過(guò)程，以使中間層組件也可以安全地訪(fǎng)問(wèn)數據。有關(guān)數據庫的細節，我們將在下一篇文章中討論。這里，我們只是指出：列出表名稱(chēng)及所有列細節、默認索引和存儲過(guò)程列表的數據庫文檔，應該包含在一個(gè)完整的數據庫設計文檔中。即，文檔中應該具有成功實(shí)現系統數據存儲部分所需的詳細信息。
注意：如果留心的話(huà)，您可能會(huì )注意到我們未提及將專(zhuān)家數據存儲在數據庫中。只是為了使項目更加有趣（同時(shí)給我們一個(gè)機會(huì )使用直接 XML 數據存儲），我們將專(zhuān)家信息存儲在一個(gè) XML 數據文件中。
數據訪(fǎng)問(wèn)組件
數據訪(fǎng)問(wèn)組件設計文檔描繪與數據存儲系統的交互以及與用戶(hù)界面的交互的所有細節。在有些系統中，數據訪(fǎng)問(wèn)組件實(shí)際上是處理過(guò)程中各種問(wèn)題的多個(gè)程序集。例如，可能會(huì )有一系列業(yè)務(wù)規則呈現在與數據存儲和檢索完全獨立的用戶(hù)界面上。在這種情況下，將業(yè)務(wù)組件與數據訪(fǎng)問(wèn)組件分開(kāi)實(shí)現可能比較明智。
在我們的示例中，實(shí)際實(shí)現的是兩個(gè)單獨的組件：Message 組件和 DataAccess 組件。如果在支持基于 XML 的數據的傳輸服務(wù)（例如 SOAP Web Service）中進(jìn)行規劃，這種面向消息的實(shí)現方案將會(huì )特別有成效。
消息組件
消息組件定義一系列用于在各圖層之間傳輸數據的類(lèi)。這些消息可以作為二進(jìn)制或 XML 文本數據存在。消息圖層的價(jià)值在于：保護系統的其余部分，使其獨立于數據存儲實(shí)現方案的具體細節，例如 SQL Server、XML 文件等。此外，通過(guò)實(shí)現消息圖層而不是更復雜的“智能對象”庫，我們的解決方案可以更輕松地支持那些不能同時(shí)發(fā)送數據和類(lèi)級別邏輯的遠程調用服務(wù)，例如 XML-SOAP。
下面是一個(gè)消息類(lèi)示例，在該示例中實(shí)現了 Topic 消息及其集合：
Public Class Topic
Private _ID As Integer
Private _Title As String
Private _Description As String
Public Property ID() As Integer
Get
Return _ID
End Get
Set(ByVal Value As Integer)
_ID = Value
End Set
End Property
Public Property Title() As String
Get
Return _Title
End Get
Set(ByVal Value As String)
_Title = Value
End Set
End Property
Public Property Description() As String
Get
Return _Description
End Get
Set(ByVal Value As String)
_Description = Value
End Set
End Property
End Class
Public Class Topics
Inherits System.Collections.CollectionBase
Default Public Property Item(ByVal index As Integer) As Topic
Get
Return CType(List(index), Topic)
End Get
Set(ByVal Value As Topic)
List(index) = Value
End Set
End Property
Public Function Add(ByVal s As Topic) As Integer
Return List.Add(s)
End Function
Public Sub Remove(ByVal index As Integer)
List.Remove(index)
End Sub
End Class
注意：如果您已嘗試過(guò)面向消息的設計，便會(huì )了解我們想要使這些消息類(lèi)系列化，以便在應用程序圖層之間輕松地來(lái)回發(fā)送。幸運的是，.NET 運行時(shí)知道如何進(jìn)行這項操作，而無(wú)需我們做過(guò)多的工作。但是，當我們學(xué)習創(chuàng )建消息的文章時(shí)，我們將詳細討論 .NET 運行時(shí)如何系列化類(lèi)，以及我們如何進(jìn)行操作以使代碼中的過(guò)程最優(yōu)化。
在后面實(shí)現消息組件和數據訪(fǎng)問(wèn)組件時(shí)，文章中將介紹此方法的細節。設計文檔將包含一個(gè)由所有信息及其屬性與數據類(lèi)型組成的列表?，F在，我們只是考慮如何使用此消息方法來(lái)封裝圖層間的數據傳輸，如何創(chuàng )建一種與本地方案和遠程方案配合使用的常規數據服務(wù)。
數據訪(fǎng)問(wèn)組件
定義消息類(lèi)的概念后，數據訪(fǎng)問(wèn)組件可以集中精力處理與數據存儲系統直接對話(huà)的細節，并以正確的消息格式返回信息。在我們的示例中，這將涉及到使用來(lái)自用戶(hù)界面的請求映射 SQL Server 存儲過(guò)程，并創(chuàng )建可返回到用戶(hù)界面進(jìn)行顯示的消息（或消息集合）。
例如，下面是一個(gè)數據訪(fǎng)問(wèn)組件的一部分示例代碼，該組件將從數據存儲中檢索單個(gè) Topic 記錄，并將正確的消息格式返回到用戶(hù)界面。
Public Function GetTopicRecord(ByVal ID As Integer) As Messages.Topic
Dim t As Messages.Topic = New Messages.Topic
cn = New SqlConnection(secureConnectionString)
cd = New SqlCommand("GetTopic", cn)
cd.CommandType = CommandType.StoredProcedure
cd.Parameters.Add("@ID", ID)
cn.Open()
dr = cd.ExecuteReader()
dr.Read()
With t
.ID = ID
.Title = dr("Title")
.Description = dr("Description")
End With
Return t
End Function
設計文檔將包括一系列用于處理來(lái)自用戶(hù)界面的各個(gè)請求的類(lèi)和方法，并含有有關(guān)調用哪個(gè)存儲過(guò)程以及返回何種消息格式的詳細信息。同樣，我們將在后面主要介紹數據訪(fǎng)問(wèn)圖層的文章中討論此過(guò)程的細節。
Web 用戶(hù)界面
最后，用戶(hù)界面設計文檔將包括完成各種方案所需的所有用戶(hù)輸入和顯示。通常來(lái)說(shuō)，用戶(hù)界面文檔包括界面機制的細節以及使用戶(hù)界面呈現唯一性的圖形設計元素。例如，配色方案、字體和總體頁(yè)面設計，與用于獲取搜索查詢(xún)的正確數據的輸入名稱(chēng)和輸入數量一樣重要。
要使文檔簡(jiǎn)潔，通常在一個(gè)與圖形設計單獨的文檔中概要描述機制細節。這是我們將要在示例中做的工作。在后面的一篇文章中，我們將創(chuàng )建一個(gè)綜合性用戶(hù)界面文檔和實(shí)現方案，詳細說(shuō)明每個(gè)屏幕的元素和相關(guān)操作。在另一篇文章中，我們將處理應用程序有關(guān)圖形的各個(gè)方面，重點(diǎn)討論作為一種外觀(guān)服務(wù)的級聯(lián)樣式表的使用。
下面是一個(gè)典型的用戶(hù)界面描述，它涉及“主題”編輯方案。
主題輸入屏幕
“主題”屏幕將顯示所有當前主題（主題 ID 和主題名稱(chēng)）的一個(gè)縮略列表，在每個(gè)主題旁邊還將顯示一個(gè)“編輯”鏈接。單擊“編輯”鏈接將會(huì )調用關(guān)聯(lián)的主題記錄并將其顯示在一系列的輸入框中。“標題”和“描述”是可編輯的，而“主題 ID”是只讀的。用戶(hù)可以編輯標題和描述，然后按“保存”按鈕將更改寫(xiě)入數據存儲。輸入將被驗證。兩者都是必需的輸入項，“標題”的長(cháng)度限制為 30 個(gè)字符，“描述”的長(cháng)度限制為 500 個(gè)字符。更新完成后，將顯示一條響應消息指出已確認更新；如果更新失敗，則顯示一條消息指出錯誤狀況。
用戶(hù)還可以刪除現有的主題記錄，方法是單擊列表中的“編輯”鏈接，審核顯示屏幕上的記錄細節后，單擊“刪除”鏈接。刪除完成后，將顯示一條響應消息指出已確認更新；如果更新失敗，則顯示一條消息指出錯誤狀況。請注意，用戶(hù)不能刪除與現有問(wèn)題或回答相關(guān)聯(lián)的主題。
此外，用戶(hù)可以完整地添加新主題記錄，方法是在初始顯示屏幕上單擊“新建主題”鏈接。將顯示“標題”和“描述”輸入（不顯示 ID 輸入）并提供一個(gè)“保存”按鈕。輸入將被驗證。兩者都是必需的輸入項，“標題”的長(cháng)度限制為 30 個(gè)字符，“描述”的長(cháng)度限制為 500 個(gè)字符。更新完成后，將顯示一條響應消息指出已確認更新；如果更新失敗，則顯示一條消息指出錯誤狀況。
利用上面的敘述，您可以輕松地實(shí)現一個(gè)完整的功能屏幕。判斷一個(gè)好的設計文檔的方法是：它能夠使讀者完成工作，且不會(huì )提出額外的問(wèn)題。最終的用戶(hù)界面設計文檔將包括應用程序中每個(gè)屏幕的此類(lèi)敘述。
小結并付諸行動(dòng)
我們簡(jiǎn)要介紹了數據庫、中間層和用戶(hù)界面實(shí)現方案的最終設計文檔。加上體系結構和初始規劃文檔，它們形成了我們的完整設計包。在實(shí)際的情況中，即使是最小的系統，完成這些文檔也至少需要幾個(gè)小時(shí)。對于大型系統，可能需要幾周甚至可能幾個(gè)月的時(shí)間。有些人可能會(huì )對此有一點(diǎn)挫敗感，但是通過(guò)事先完成這些工作，您可以在進(jìn)入項目的編碼階段之前很早就了解完成解決方案面臨的幾乎所有主要障礙。這樣可以減少編寫(xiě)實(shí)際代碼的時(shí)間，并且還可以減少您會(huì )遇到的錯誤和障礙的數量。
在下一篇文章中，我們將討論使用 Visual Studio .NET 在 SQL Server 中建立數據存儲系統的有關(guān)細節。我們將定義數據表，創(chuàng )建必需的存儲過(guò)程，并設置正確的數據訪(fǎng)問(wèn)，以確保任何組件和數據本身之間具有安全可靠的連接。
聯(lián)系客服
