ASP.NET應用程式規劃與設計(2)

ASP.NET應用程式規劃與設計(2)

作者： Microsoft   www.ASPCool.com 時間:2003-11-16 18:00:47  閱讀次數:14684

文檔化使用者方案      　　使用者方案沒有什麼令人驚異之處。通常，它們只是描述使用者如何與應用程式互動。使用者方案的關鍵價值在於記錄了關於每個人對使用者希望系統如何運行以及應用程式應如何響應的設想。通過完成這個過程，您將可以完全瞭解處理各種使用者與系統的互動時所需的資料點和函數。換句話說，編寫完善的使用者方案將有助於您確定完成解決方案需要實現的資料庫、中介軟體和使用者介面元素。      　　注意：Visual Studio .NET Enterprise Architect 有一項非常不錯的功能，即允許您使用 Microsoft Visio? 通過 UML（整合模組化語言）建立使用者方案，然後產生這些方案的基本代碼。在這裡，我不打算深入探討這些細節，但是您可以在 MSDN? Academic Alliance 網站找到一篇關於這一主題的好文章 Generating .NET Code Using Visio Enterprise Architect's UML，作者是 Sreedhar Koganti。   有了上一節的目標聲明後，下面是 DotNetKB 項目的幾個樣本使用者方案。      　　搜尋知識庫      　　匿名使用者可以輸入一個或多個關鍵字並執行搜尋，搜尋將返回包含這些關鍵字的問題和/或回答列表。使用者可以將關鍵字搜尋鎖定在僅搜尋問題、僅搜尋回答或者二者都搜尋。返回的列表將顯示問題及其回複數和被其他使用者訪問的次數。單擊連結將返回以時間先後逆序排列的回複（純文字）列表。      　　將新問題輸入到知識庫中      　　匿名使用者可以瀏覽用於向資料庫輸入新問題以供授權專家審閱和回複的螢幕。使用者可以輸入問題的標題和內容，並可以選擇在一系列主題中的某個主題下記錄該問題。使用者還可以輸入他們的名字和相關的 URL（電子郵件、Web 地址等）。輸入將被驗證，以確保包含必需的資料並確保所有輸入資料不會受到指令碼攻擊等。一旦資料經過驗證並被儲存到資料庫中，使用者將看到一個響應螢幕，感謝使用者的支援並將使用者直接連接到首頁。此外，使用者還可以選擇讓該網站“記住”他們的姓名和 URL 以備以後訪問該網站時使用。      　　您已經瞭解它的工作原理了，對嗎？每一個方案都嘗試細化使用者互動的重要方面。例如，上面列出的兩個方案表明使用者為“anonymous”（匿名使用者），這表示這類使用者不需要登入或進行其他方式的授權。第二個樣本還標識了若干輸入值、驗證步驟和可選操作。      　　當然，這隻是兩個樣本；完整的系統需要更多的方案。此外，需要特別注意的是，“使用者”不僅僅可以是人，也可以是您的程式需要與其通訊的其他應用程式，甚至還可以是您的應用程式的其他部分。例如，一個方案描述首頁如何列出最近添加到知識庫中的內容，以供任何人查看。此例中的“使用者”將是首頁自身。還有一些方案描述專家如何尋找和回複新問題以及管理員如何更新主題列表並管理系統的其他部分。我已為討論這個簡單的應用程式識別碼了 20 多種方案。您可以在 DotNetKB 中找到當前列表（以及與此項目相關的所有其他資料）。      　　至此我們就有了目標聲明和一些使用者方案。現在，是時候稍憩一下，然後學學一些技術了。我們需要定義應用程式體繫結構，這可以協助我們以“鮮活有效代碼”實際實現方案。      　　定義應用程式體繫結構      　　有了基本的目的和為解決方案開發的使用者方案列表後，您需要開始籌劃整體的體繫結構。主要目標是標識應用程式的邏輯方面和物理方面，即如何將應用程式拆分為各種有用的部分。在本節中還添加了安全性方面的內容。安全是在規劃的“一開始”您就需要考慮的問題，而不是在開發週期中“最後添加”的內容。我們稍後會在本節中詳細討論這個問題。      　　邏輯體繫結構      　　從邏輯上講，您需要規劃解決方案以標識資料存放區、資料訪問、商務規則、使用者介面等之間的“邊界”。通常，Web 開發人員會選擇一個兩階段模型，並用 Web Form儲存用於訪問現有資料存放區系統（例如 Microsoft SQL Server）的所有代碼。一個更有效方法是建立一個位於 Web Form使用者介面與 SQL Server 資料存放區系統之間的中介層組件庫。這種三層方法（Web Form、組件、資料庫）通常是大多數應用程式所需的。但是，在某些情況下，可能需要一個其他層來處理伺服器之間傳輸的資料。這個傳輸層可以使用獨立於平台的協議（例如 XML-SOAP）來實現。但是，如果您從頭到尾都使用 Microsoft .NET 技術，則可以使用 .NET 遠程協議的二進位版來完成這一任務，而且速度比使用 XML-SOAP 要快得多。      　　對於我們的樣本，我們將定義三個邏輯邊界：使用者介面（Web Form）、中介層（一個 .NET 組件程式集）和資料層（SQL Server 資料庫）。圖 1 顯示了如何表示這一內容。         圖 1：三層圖      　　現在我們有一個簡單的邏輯模型。它是如何起作用的？它有助於我們考慮各個邏輯組之間的邊界。每個邏輯層應盡量與其他層獨立。理想的情況是，圖層中的更改應該對整體產生最小的影響。例如，如果將資料存放區從 SQL Server 更改到 XML 資料檔案，唯一受到影響的圖層應是中介層圖層。使用者介面應該根本無需考慮更改。這會使您進行思考：如何?解決方案的實際編碼以實現此原則。      　　另外，邏輯層有助於我們考慮安全問題。各個圖層之間的邊界都存在潛在的安全性漏洞。而且，各個圖層可能有自己特定的安全措施（SQL Server 許可權、.NET 運行時許可權、ASP.NET 安全等）。同樣，我們稍後會在本節中詳細討論這個問題。