應用邏輯規劃—深入了解 Tim Corey 的方法
在他的C# App從開始到完成系列中,Tim Corey解釋建置應用程式不僅僅是撰寫程式碼。 真正的挑戰在於規劃應用程式的邏輯——應用程式的不同部分將如何互動、溝通以及在螢幕和元件間移動資料。 在邏輯規劃的第05課中,Tim著重於邏輯規劃,強調這是您決定應用程式整體行為的階段。
他提醒我們到目前為止,課程已經涵蓋了範圍需求、建構整體結構、設計資料後端以及設計前端。 現在,Tim說,下一步是透過邏輯將一切連接起來。
Tim澄清說,這節課不會深入程式碼。 相反地,他想要涵蓋應用程式背後的整體想法、宏觀視圖以及邏輯。 他鼓勵用紙寫下筆記,畫箭頭來繪製出每個表單和按鈕應該如何行為,這與在專業開發環境中規畫業務過程的方式相似。 此規劃有助於在進入程式碼之前讓應用程式的邏輯變得清晰。
為什麼邏輯規劃很重要
Tim首先指出,連接表單是應用程式邏輯的主要部分。 一旦表單正確連接,剩下的任務通常較小。 他解釋說,邏輯規劃過程幫助您理解應用程式必須支援的功能、流程和控制項。
Tim說,如果他在紙上進行這項工作,他會寫下每個元件應該做什麼,並在它們之間畫箭頭。 即使課程是在螢幕上進行的,他仍然計畫逐一瀏覽每個表單,並解釋每部分背後的邏輯。
建立比賽表單邏輯
Tim從建立比賽表單開始,這是較簡單的表單之一。 他解釋了每個按鈕背後的邏輯以及它們應該如何協同工作。
建立新團隊按鈕
Tim解釋說,建立新團隊按鈕會開啟建立團隊表單。 在創建團隊後,新表單會關閉,創建的團隊資料會返回到建立比賽表單。 團隊應該出現在團隊/球員清單方框中,這是透過創建一個可以從建立團隊表單中呼叫的方法來完成的。
Tim還引入了使用介面的概念進行這種通訊,解釋說介面允許表單在不知道對方的情況下進行互動。 這是一個經典的例子,說明業務邏輯和軟體架構如何協同工作以保持元件之間的品質、完整性和清晰的互動。
添加團隊按鈕
Tim解釋說,添加團隊按鈕很簡單。 它檢查下拉列表中的哪個項目被選中,將該團隊添加到比賽列表中,從下拉列表中移除它,然後刷新這兩個列表。 此邏輯確保使用者的選擇在UI和基礎資料中正確反映。
建立獎勵按鈕
Tim解釋說,建立獎勵按鈕的行為類似於建立新團隊按鈕。 它打開創建獎勵表單,等待獎勵被創建,然後將該獎勵添加到獎勵列表方框中。 邏輯是一樣的,但類別和資料類型不同。
刪除選定按鈕
Tim解釋說,刪除按鈕從列表方框中刪除選定的項目。 在團隊的情況下,邏輯還將刪除的團隊返回到下拉列表中,以確保使用者可以稍後再次添加它。 這類實時更新提高了用戶體驗,並有助於在UI中保持正確的資料。
建立比賽按鈕
Tim解釋說,這是一個重要的按鈕,因為它觸發了最多的邏輯。 當點擊時,它必須驗證所有資訊:
-
比賽名稱不能為空
-
參賽費用不能為負
- 至少必須有兩個隊伍
驗證後,Tim解釋下一個主要步驟:創建賽程表。 比賽賽程邏輯決定了比賽中應該有多少隊伍,並且需要多少輪空。 Tim參考了一份附件文件,他在其中寫下了計算此公式的方法。 例如,假設比賽有10個隊伍,比賽必須從16個隊伍開始,這意味著第一輪需要6個輪空。
Tim還指出,邏輯需要隨機安排第一輪的順序。 一旦所有這些完成,表單就完成了,應用程式可以繼續前進。
建立團隊表單邏輯
Tim轉向建立團隊表單,解釋其按鈕背後的邏輯。
添加成員按鈕
Tim說這個按鈕將現有成員從下拉列表添加到團隊列表方框中。 然後從下拉列表中移除該成員,並刷新兩個列表。 Tim強調這與添加團隊按鈕的邏輯相似。
創建成員按鈕
Tim解釋說,創建成員按鈕會用四個輸入框創建一個新的團隊成員,添加到列表方框中,然後清除這四個框。 這是應用程式邏輯中常見任務的典型例子,用戶輸入必須被處理並反映在UI中。
創建團隊按鈕
Tim說,創建團隊按鈕必須驗證團隊,然後將創建的團隊返回給呼叫者。 他注意到,這個表單缺少一個刪除球員按鈕,應該添加以匹配其他表單並提供一致的用戶體驗。 Tim解釋說,一致的UI行為對於用戶熟悉和舒適度至關重要。
建立獎勵表單邏輯
Tim將建立獎勵表單描述為較簡單。 它有四個文字框和一個按鈕。
當點擊創建獎勵按鈕時,它:
-
驗證獎勵資訊
-
將資料返回給呼叫表單
- 關閉表單
Tim解釋說,此表單基本上與建立團隊表單相同,但元件較少。
比賽儀表板邏輯
Tim解釋,比賽儀表板表單很簡單但至關重要。
它列出現有的比賽。 加載比賽按鈕開啟選定比賽的比賽查看器,而建立比賽按鈕打開建立比賽表單。
Tim指出,當比賽建立時,它應該被加入下拉列表,以便用戶可以立即加載它。 此邏輯是應用程式中資料存取和實時更新的一個基本例子。
比賽查看器邏輯
Tim描述比賽查看器是最複雜的表單,因為它包含最多的邏輯。
比賽名稱
Tim解釋說,當表單加載時,比賽名稱會被更新。 表單接收比賽物件並顯示名稱。
輪次下拉框
Tim解釋說,這個下拉框是計算得出的,而不是從資料庫加載的。 它查看輪次列表並確定存在多少輪次。如果比賽有四輪,下拉框必須顯示第一輪到第四輪。
僅顯示未比賽的遊戲核取框
Tim說,如果核取框被選中(預設),對賽清單方框會過濾為僅顯示尚未比賽的遊戲。 如果未選中,所有對賽都會顯示。
對賽得分部分
Tim解釋說,選擇對賽會更新右側部分顯示團隊名稱和得分。 得分按鈕允許用戶更新得分並完成對賽。
觸發下一輪
Tim解釋說,當一輪的最後對賽的得分被設置時,下一輪應開始。 如果是最終的冠軍賽,則比賽結束,獎勵被分配。 Tim還指出,系統會在參賽者被安排比賽以及比賽結果可用時寄出電子郵件給參賽者。
得分編輯規則
Tim詢問得分設置後是否可以更新。 他得出結論是可以,但僅在當前輪次仍然有效時。如果得分在下一輪開始後被更改,可能會導致嚴重問題,因為團隊可能會與錯誤對手比賽。
因此,Tim說得分按鈕需要有邏輯,以確保得分只能在當前輪次中更改。
接下來呢?
Tim承認,還有一些邏輯需要規劃,比如:
-
資料存取與儲存
-
處理不同的資料來源
-
電子郵件邏輯
- 觸發對賽
他說這些在程式碼中更好規劃,因此團隊會在開始編碼後解決它們。 這是一個軟體開發中業務完整性的例子—在執行時建置和適應,而非過度規劃。
結論:在編碼前規劃
Tim在他的影片中總結道,規劃階段已完成:
-
資料設計已完成
-
UI佈局已繪製
- 每个表单背后的邏輯已規劃
下一步是將其轉換為代碼。 在下一堂課,Tim將創建類別庫並開始將資料設計實作到實際應用程式中。
