談談 ASP.NET 規劃階段的設計[轉貼：]

　　　在直接進入項目的編碼部分之前，需要花一點時間實際勾畫出應用程式的邏輯組件，這非常重要。在我們的樣本解決方案中，我們要實現解決方案的三個邏輯組件：資料庫、.NET 資料訪問組件和 ASP.NET 使用者介面。現在，我們先勾畫出每個組件的大致輪廓，討論過程中最重要的方面，即文檔化組件間的互動。 

資料庫 

對於 DotNetKB 應用程式，我們需要將資料存放區在三張表中：主題、問題和回答（請參閱）。 

圖 3：主題、問題和回答表

我們需要使用預存程序，以使中介層組件也可以安全地訪問資料。這裡，我們只是指出：列出表名稱及所有列細節、預設索引和預存程序列表的資料庫文檔，應該包含在一個完整的資料庫設計文檔中。即，文檔中應該具有成功實現系統資料存放區部分所需的詳細資料。 

注意：如果留心的話，您可能會注意到我們未提及將專家資料存放區在資料庫中。只是為了使項目更加有趣（同時給我們一個機會使用直接 XML 資料存放區），我們將專家資訊儲存在一個 XML 資料檔案中。 

資料訪問組件 

資料訪問組件設計文檔描繪與資料存放區系統的互動以及與使用者介面的互動的所有細節。在有些系統中，資料訪問組件實際上是處理過程中各種問題的多個程式集。例如，可能會有一系列商務規則呈現在與資料存放區和檢索完全獨立的使用者介面上。在這種情況下，將業務組件與資料訪問組件分開實現可能比較明智。 

在我們的樣本中，實際實現的是兩個單獨的組件：Message 組件和 DataAccess 組件。如果在支援基於 XML 的資料的傳輸服務（例如 SOAP Web Service）中進行規劃，這種面向訊息的實現方案將會特別有成效。 

訊息組件 

訊息組件定義一系列用於在各圖層之間傳輸資料的類。這些訊息可以作為二進位或 XML 文本資料存在。訊息圖層的價值在於：保護系統的其餘部分，使其獨立於資料存放區實現方案的具體細節，例如 SQL Server、XML 檔案等。此外，通過實現訊息圖層而不是更複雜的“智能對象”庫，我們的解決方案可以更輕鬆地支援那些不能同時發送資料和類層級邏輯的遠程調用服務，例如 XML-SOAP。 

下面是一個訊息類樣本，在該樣本中實現了 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
 

注意：如果您已嘗試過面向訊息的設計，便會瞭解我們想要使這些訊息類系列化，以便在應用程式圖層之間輕鬆地來回傳送。幸運的是，.NET 運行時知道如何進行這項操作，而無需我們做過多的工作。但是，當我們學習建立訊息的文章時，我們將詳細討論 .NET 運行時如何系列化類，以及我們如何進行操作以使代碼中的過程最佳化。 

在後面實現訊息組件和資料訪問組件時，文章中將介紹此方法的細節。設計文檔將包含一個由所有資訊及其屬性與資料類型組成的列表。現在，我們只是考慮如何使用此訊息方法來封裝圖層間的資料轉送，如何建立一種與本地方案和遠程方案配合使用的常規資料服務。 

其它的資料訪問組件 

定義訊息類的概念後，資料訪問組件可以集中精力處理與資料存放區系統直接對話的細節，並以正確的訊息格式返回資訊。在我們的樣本中，這將涉及到使用來自使用者介面的請求映射 SQL Server 預存程序，並建立可返回到使用者介面進行顯示的訊息（或訊息集合）。 

例如，下面是一個資料訪問組件的一部分範例程式碼，該組件將從資料存放區中檢索單個 Topic 記錄，並將正確的訊息格式返回到使用者介面。 

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
 

設計文檔將包括一系列用於處理來自使用者介面的各個請求的類和方法，並含有有關調用哪個預存程序以及返回何種訊息格式的詳細資料。同樣，我們將在後面主要介紹資料訪問圖層的文章中討論此過程的細節。 

Web 使用者介面 

最後，使用者介面設計文檔將包括完成各種方案所需的所有使用者輸入和顯示。通常來說，使用者介面文檔包括介面機制的細節以及使使用者介面呈現唯一性的圖形設計項目。例如，色彩配置、字型和總體頁面設計，與用於擷取搜尋查詢的正確資料的輸入名稱和輸入數量一樣重要。 

要使文檔簡潔，通常在一個與圖形設計單獨的文檔中概要描述機制細節。這是我們將要在樣本中做的工作。在後面的一篇文章中，我們將建立一個綜合性使用者介面文檔和實現方案，詳細說明每個螢幕的元素和相關操作。在另一篇文章中，我們將處理應用程式有關圖形的各個方面，重點討論作為一種外觀服務的階層式樣式表的使用。 

下面是一個典型的使用者介面描述，它涉及“主題”編輯方案。 

主題輸入螢幕 

“主題”螢幕將顯示所有當前主題（主題 ID 和主題名稱）的一個縮減列表，在每個主題旁邊還將顯示一個“編輯”連結。單擊“編輯”連結將會調用關聯的主題記錄並將其顯示在一系列的輸入框中。“標題”和“描述”是可編輯的，而“主題 ID”是唯讀。使用者可以編輯標題和描述，然後按“儲存”按鈕將更改寫入資料存放區。輸入將被驗證。兩者都是必需的輸入項，“標題”的長度限制為 30 個字元，“描述”的長度限制為 500 個字元。更新完成後，將顯示一條響應訊息指出已確認更新；如果更新失敗，則顯示一條訊息指出錯誤狀況。 

使用者還可以刪除現有的主題記錄，方法是單擊列表中的“編輯”連結，審核顯示螢幕上的記錄細節後，單擊“刪除”連結。刪除完成後，將顯示一條響應訊息指出已確認更新；如果更新失敗，則顯示一條訊息指出錯誤狀況。請注意，使用者不能刪除與現有問題或回答相關聯的主題。 

此外，使用者可以完整地添加新主題記錄，方法是在初始顯示螢幕上單擊“建立主題”連結。將顯示“標題”和“描述”輸入（不顯示 ID 輸入）並提供一個“儲存”按鈕。輸入將被驗證。兩者都是必需的輸入項，“標題”的長度限制為 30 個字元，“描述”的長度限制為 500 個字元。更新完成後，將顯示一條響應訊息指出已確認更新；如果更新失敗，則顯示一條訊息指出錯誤狀況。 

利用上面的敘述，您可以輕鬆地實現一個完整的功能螢幕。判斷一個好的設計文檔的方法是：它能夠使讀者完成工作，且不會提出額外的問題。最終的使用者介面設計文檔將包括應用程式中每個螢幕的此類敘述。 

小結並付諸行動 

我們簡要介紹了資料庫、中介層和使用者介面實現方案的最終設計文檔。加上體繫結構和初始規劃文檔，它們形成了我們的完整設計包。在實際的情況中，即使是最小的系統，完成這些文檔也至少需要幾個小時。對於大型系統，可能需要幾周甚至可能幾個月的時間。有些人可能會對此有一點挫敗感，但是通過事先完成這些工作，您可以在進入項目的編碼階段之前很早就瞭解完成解決方案面臨的幾乎所有主要障礙。這樣可以減少編寫實際代碼的時間，並且還可以減少您會遇到的錯誤和障礙的數量。 

至此，您已經看到了一個如何建立應用程式規劃的可用樣本，可以開始考慮如何在您自己的工作中使用這些元素來提高項目的整體品質和生產率。有關專案規劃以及規劃如何影響軟體品質的詳細資料，請參閱 Steve McConnell 的Software Project Survival Guide。