實施方法理念
瀑布法
實施應用程式的瀑布方法要求設計人員諮詢最終使用者組織的一個或多個代表並寫下所有應用程式規格。通常，規格包含在一組功能文件或用例中，以便最終使用者可以輕鬆閱讀和理解這些文件。
最終使用者簽署這些文檔，然後設計應用程式的技術設計團隊收集這些文檔，建立各種工件，例如類別模型圖、狀態圖、活動圖和資料模型。此階段的目標是詳細編寫所有內容，以便開發人員可以毫無問題地創建必要的程式碼。設計正式移交給開發團隊和測試團隊。交付後，開發團隊開始編碼，測試團隊使用技術設計結合用例來建立測試案例和測試場景。
開發團隊完成編碼後，將程式碼交給測試團隊。測試團隊根據需求和詳細設計執行其設計的測試。任何問題將由開發團隊解決。測試和修復過程完成後，應用程式將移交給最終用戶進行驗收測試。最終用戶執行最終檢查以查看應用程式是否符合初始要求。如果獲得批准，他就會批准成品並完成專案。開發團隊完成編碼後，將程式碼交給測試團隊。
測試團隊根據需求和詳細設計執行其設計的測試。任何問題將由開發團隊解決。測試和修復過程完成後，應用程式將移交給最終用戶進行驗收測試。最終用戶執行最終檢查以查看應用程式是否符合初始要求。如果獲得批准，他就會批准成品並完成專案。開發團隊完成編碼後，將程式碼交給測試團隊。測試團隊根據需求和詳細設計執行其設計的測試。
任何問題將由開發團隊解決。測試和修復過程完成後，應用程式將移交給最終用戶進行驗收測試。最終用戶執行最終檢查以查看應用程式是否符合初始要求。如果獲得批准，他就會批准成品並完成專案。
最終用戶執行最終檢查以查看應用程式是否符合初始要求。如果獲得批准，他就會批准成品並完成專案。最終用戶執行最終檢查以查看應用程式是否符合初始要求。如果獲得批准，他就會批准成品並完成專案。
使用瀑布方法時，專案可以有更多或更少的階段，但主要特徵是每個階段都有非常正式的開始和結束，以及非常正式的可交付成果。
瀑布方法的優點是負責每個階段的團隊的責任更大。很清楚他們需要交付什麼、何時交付以及需要交付給誰。很多時候，開發團隊不需要與使用者互動。當將開發外包給另一個國家時，這非常有用。
瀑布方法的主要缺點是，在一切都以非常正式的方式組織的環境中，反應變化的靈活性會降低。連搬家也需要組織。似乎很少有公司能夠有效地做到這一點，這往往會導致間接費用的大幅增加。為了管理專案成本，一些公司甚至推遲對需求的任何更改，直到應用程式的初始交付，從而有效地交付了無法滿足最終用戶需求的應用程式。
敏捷開發
許多長期運行的軟體開發專案都超出了預算，並且未能按時交付產品。敏捷軟體開發理念的前提是透過在稱為迭代的短時間內開發軟體來最大限度地降低風險，迭代通常持續一到四個星期。每次迭代就像它自己的微型軟體項目，包括發布新功能增量所需的所有任務：規劃、需求分析、設計、編碼、測試和文件。雖然迭代可能無法添加足夠的功能來保證產品發布，但敏捷軟體專案的目標是能夠在每次迭代結束時發布新軟體。在每次迭代結束時，團隊都會重新評估專案優先順序。
敏捷軟體開發的目標是透過快速、持續地交付有用的軟體來實現客戶滿意度；始終致力於打造顧客所需的產品；歡迎而不是反對後期對要求的變更；定期適應不斷變化的環境；創業者和開發者之間有著密切的、日常的合作，其中面對面的交談是最好的溝通形式。
敏捷軟體開發的主要優點是能夠靈活地處理變更，並始終致力於根據業務需求進行交付。當然，缺點是管理範圍、規劃和預算的複雜性增加。另一個常見風險是對（技術）文件的關注有限。
漸進式開發
增量軟體開發是敏捷開發和瀑布式開發的結合。應用程式是逐步設計、實現和測試的，以便每個增量都可以交付給最終用戶。直到最後一個增量完成後，該項目才算完成。它旨在透過定義中間增量並利用敏捷開發的一些優勢來縮短瀑布。根據先前增量收到的回饋，可以在交付下一個增量時進行調整。下一個增量可以包含新程式碼以及先前提供的程式碼的修改。
優點是手續仍然存在，但變更管理變得更容易。多次測試和部署應用程式的成本將比只進行一次更高。
程序流程控制
選擇程式流程控制的方法是一項非常架構性的任務。目標是創建應用程式的藍圖，一旦您開始添加功能和程式碼，一切似乎都有自己的位置。如果您曾經審查過或編寫過高品質程式碼，您就會理解這項原則
組織程式碼
設計程序流程的第一步是組織程式碼，建立一組規則來幫助建立應用程式的計畫或大綱。由於程式碼位於一個邏輯位置，因此維護、偵錯和錯誤修復將更加容易。完成基礎工作後，您可以選擇一種方法來實作應用程式邏輯。
設計模式應該在程式流程控制的設計中發揮重要作用。多年來，針對重複出現的問題編寫了大量程式碼並設計了許多解決方案。這些解決方案是在設計模式中建立的。將設計模式應用於常見的軟體設計問題將幫助您創建易於識別且可由同行實施的解決方案。獨特的問題仍然需要獨特的解決方案，但您可以使用設計模式來引導您解決這些問題。
創建專案
層數
第一步是考慮邏輯層。請注意，層與層不同，它們經常被混淆，甚至被認為是相同的。
層與層
層是為了在程式碼中建立邊界。上層可以引用下層的程式碼，但圖層永遠不能引用高層的程式碼。分層涉及層在多台電腦上的物理分佈。例如，在三層應用程式中，使用者介面設計為在桌面電腦上運行，應用程式邏輯設計為在應用程式伺服器上運行，資料庫運行在資料庫伺服器上。每層可以由多層組成。
圖 8-1：基本的三層組織
層是指抽象層級。圖 8-1 所示的層適用於大多數應用程式。這些層級也稱為三個主要層，並且可以有多個其他名稱。一般來說，表示層的程式碼可以呼叫應用邏輯層的服務，但應用邏輯層不能呼叫表示層的方法。表示層永遠不應該直接呼叫資料存取層，因為這會繞過應用程式邏輯層實現的職責。資料存取層永遠不應該呼叫應用程式邏輯層。
圖層只是一種抽象，實現圖層最簡單的方法可能是在專案中建立資料夾並將程式碼新增至適當的資料夾。更有用的方法是將每個層放置在單獨的專案中，從而建立單獨的程序集。將應用程式邏輯放在庫程式集中的優點是，它允許您使用 Microsoft Visual Studio 或 NUnit 建立單元測試來測試邏輯。它還為選擇每一層的部署位置提供了靈活性。
物理層
在企業應用程式中，您應該預期同一邏輯有多個客戶端。事實上，應用程式成為企業應用程式的原因在於它將部署在三層中：客戶端、應用程式伺服器和資料庫伺服器。由貴公司銷售部門創建的 Microsoft Office Access 應用程式雖然對銷售部門非常重要，但並不構成企業應用程式。
請注意，應用程式邏輯和資料存取層通常會一起部署在應用程式伺服器上。設計專案的一部分是選擇是否使用.NET或Web遠端服務存取應用程式伺服器。無論您選擇什麼，您都會添加一些程式碼以輕鬆存取表示層的遠端服務。如果您使用 Web 服務存取應用程式伺服器上的服務，Visual Studio .NET 會為您完成這項工作並產生代理程式碼，自動提供遠端代理模式的實作。
將圖案新增至圖層
這三個基本層提供了高級概述。讓我們加入一些結構模式來創造強大的企業架構。結果如圖8-2所示。
重點在於應用邏輯層。圖 8-2 顯示了使用外觀模式存取應用程式邏輯。外觀是一個對象，它為更大的程式碼體（例如類別庫）提供簡化的介面。外觀可以減少外部程式碼對庫內部工作的依賴，因為大多數程式碼都使用外觀，從而使系統開發更加靈活。為此，外觀將為細粒度物件的集合提供粗粒度介面。
決策流程
程式流控制，也稱為決策流，涉及如何在應用程式邏輯層中設計服務，或者如您在上一段中看到的，如何在外觀中設計方法。
有兩種組織服務的方法：
- 行動導向
- 國家導向
以行動為導向的方法
透過根據使用者操作組織服務，您可以透過提供服務來實現應用程式邏輯，每個服務處理來自表示層的特定請求。這也稱為事務腳本模式。這種方法很受歡迎，因為它簡單且感覺非常自然。遵循此方法的方法範例有 BookStoreService.AddNewOrder(Order order) 和 BookStoreService.CancelOrder(int orderId)。
執行操作所需的邏輯在方法內非常順序地實現，使其非常可讀，但也更難以重複使用程式碼。使用其他設計模式（例如表模組模式）可以幫助提高可重複使用性。
國家導向的方法
還可以以更面向狀態的方式實現應用程式的決策流程。應用程式伺服器提供的服務本質上較為通用，例如BookStoreService.SaveOrder(Order order)。此方法將查看訂單狀態並決定是否新增訂單或取消現有訂單。
資料結構項目
在設計資料結構時，您必須做出多種選擇。第一個選擇是資料儲存機制，第二個是資料的預期用途，第三個是版本控制需求。可以透過三種方式來看待資料結構設計：
- 服務提供數據；數據是關係資料庫的反映。
- 資料必須映射到對象，並且服務提供對對象的存取。
- 服務提供的數據必須是基於模式的。
應在設計過程的早期階段選擇三者之一作為資料流結構的基礎。許多公司都有公司政策，要求所有專案都選擇三個選項之一，但如果可能，您應該重新評估每個專案的選項，為手頭上的專案選擇理想的方法。
選擇資料儲存引擎
在設計應用程式時，毫無疑問，您必須設計某種類型的資料儲存。可以使用以下儲存和資料儲存形式：
- 記錄
- 應用程式設定檔
- XML 檔案
- 純文字文件
- 資料庫
- 訊息佇列
每家商店都有自己獨特的特點，可以根據具體要求進行客製化。
設計資料流
使用 ADO.NET 的資料流
在應用程式邏輯層中實作以資料為中心的服務時，您將使用 ADO.NET 設計資料流。 .NET Framework 類別庫提供了廣泛的應用程式介面 (API)，用於操作託管程式碼中的資料。該 API 稱為 ADO.NET，可以在 System.Data 命名空間中找到。媒體和資料儲存的完全分離是ADO.NET 的一個重要設計特徵。 DataSet、DataTable 和 DataRow 等類別旨在儲存數據，但它們不保留任何資料來源的資訊。它們被認為與資料來源無關。一組單獨的類別（例如 SqlConnection、SqlDataAdapter 和 SqlCommand）負責連接到資料來源、擷取資料以及填入 DataSet、DataTable 和 DataRow。這些類別位於子命名空間中，例如 System.Data.Sql、System.Data.OleDB、System.Data.Oracle 等。根據您要連接到的資料來源，您可以在正確的命名空間中使用類，並且根據您所使用的產品的範圍，您會發現這些類別提供了或多或少的功能。
由於 DataSet 未連接到資料來源，因此可以非常成功地使用它來管理應用程式中的資料流。圖 8-5 顯示了執行此操作時的資料流。
讓我們來看看這個項目，想像一下有人登入您的書店並訂購了三本書。表示層管理購物車的狀態。客戶已準備好下訂單並已提供所有必要的數據。他選擇發送訂單。網頁將所有資料轉換為一個DataSet，其中包含兩個DataTable，一個用於訂單，一個用於訂單；為請求插入一個 DataRow；並為訂單行插入三個資料行。然後，網頁再次將此資料顯示回用戶，控制資料綁定到資料集，並詢問您確定嗎？使用者確認請求並將其提交到應用程式的邏輯層。應用程式邏輯層檢查 DataSet 以查看所有必填欄位是否都有值，並執行檢查以查看使用者是否擁有超過 US$ 1,000。 00 未付帳單。如果一切正常，DataSet 將會傳遞到資料存取層，資料存取層連接資料庫並根據 DataSet 資訊產生插入指令。
以這種方式使用 DataSet 是建立應用程式並使用 Framework 類別庫的強大功能和 ASP.NET 將資料綁定到多個控制項（例如針對 DataSet 的 GridView）的能力的快速有效的方法。您可以使用類型化 DataSet 對象，而不是使用簡單的 DataSet 對象，並透過在表示層和應用程式邏輯層中實現程式碼來改善編碼體驗。這種方法的優點也是方法的缺點。對資料模型的微小更改並不一定會導致許多方法必須更改其簽章。所以在維護方面，這個效果非常好。如果您還記得表示層不一定是使用者介面，它也可以是 Web 服務。如果您修改 DataSet 定義，也許是因為您正在重命名資料庫中的字段，那麼您正在修改承保該資料集的契約。web 服務。正如您可以想像的，這可能會導致一些重大問題。如果表示層只是一個使用者介面，則此方案效果很好，但對於外部系統或元件的接口，您需要隱藏應用程式的內部工作原理並將資料轉換為資料模型的直接克隆之外的其他內容，並且您將需要建立資料傳輸物件（DTO）。
使用物件關係映射的資料流
使用 ADO.NET 的資料流是一種以資料為中心的資料流管理方法。數據和邏輯是離散的。另一方面是採用更物件導向的方法。在這裡，建立類別來對資料和行為進行分組。目標是定義模擬在為其創建應用程式的業務域中找到的資料和行為的類別。結果通常稱為業務對象。組成應用程式的業務物件的集合稱為領域模型。一些開發人員聲稱豐富的領域模型更適合設計更複雜的邏輯。很難證明或反駁這樣的說法。只要知道你有選擇，並且決定權在你自己。
圖 8-6 顯示了與圖 8-5 類似的資料流，只不過現在您新增了物件關係映射層並用不同的資料載體取代了 DataSet 物件。
現在按照之前的步驟進行同樣的操作；想像一下，有人登入您的書店並訂購了三本書。表示層管理購物車的狀態。客戶已準備好下訂單並已提供所有必要的數據。他選擇發送訂單。該網頁將所有數據轉換為 DTO，保存一個訂單和三個訂單行的數據，並根據需要建立物件。網頁再次將此資料顯示回用戶，使用 ASP.NET 2.0 中的 ObjectDataSource 對 DTO 進行資料綁定控制，並詢問“您確定嗎？”使用者確認選擇並將 DTO 提交到應用程式的邏輯層。應用程式邏輯層將 DTO 轉換為 Order 類型的業務對象，其屬性包含三個 OrderLine 物件。訂單方法。呼叫 Validate() 來驗證訂單並檢查所有必填欄位是否都有值，並檢查使用者的未清發票中是否有超過 R$ 1,000.00 的金額。為此，訂單將呼叫 Order.Customer.GetOutstandingBills()。如果一切正常，則呼叫 Order.Save() 方法。訂單將提交到物件關聯映射層，其中訂單和訂單線被映射到DataSet中的DataTable，並且DataSet被傳遞到資料存取層，資料存取層連接到資料庫並根據其中的資訊產生插入命令資料集。當然，可以透過多種方式進行物件關係映射，但並非所有方式都包含轉換為資料集。有些會直接建立插入語句，但仍會使用資料存取層來執行該語句。
正如您所看到的，發生了一些轉變。使用 DTO 是必要的，因為業務對象實現行為並且行為可能會發生變化。為了最大限度地減少這些變更對錶示層的影響，您需要將資料從業務物件轉換為資料傳輸物件。在Java中，資料傳輸物件通常稱為值物件。
使用業務對象的一大優點是它確實有助於組織程式碼。如果您回顧一段複雜的邏輯，它通常非常具有可讀性，因為其中的管道代碼很少。缺點是大多數資料儲存仍然是關係型的，並且將業務物件對應到關係型資料可能會變得相當複雜。
基於模式的服務
在管理資料流方面，您剛剛看到了兩個相反的情況。許多變化是可能的。常見的變體是資料集用作資料儲存的基本使用者介面資料支持，但單獨的模式 (DTO) 用於從其他系統呼叫的 Web 服務。應用層將關係資料轉換為預先定義的模式。這樣做的主要優點是引用該服務的任何應用程式都不依賴元件的任何類型的內部實作。這使得版本控制更加靈活，介面向後相容，並且能夠在不更改服務介面的情況下更改元件實作。
當然，您可以在Web 應用程式中使用業務物件並繞過DTO 轉換，但這通常只有在應用程式邏輯與Web 應用程式一起實作時才有效。請記住，要呼叫Order.Save()，您將需要一個資料庫連線。這是否可取取決於您以及您的安全總監。