設計應用數據（第 03 課）—與 Tim Corey 深入探討
在"C# App Start to Finish"課程的第三節課中，Tim Corey 帶我們了解資料設計的關鍵步驟。 他解釋說，在開始構建用戶介面或編寫代碼之前，您必須首先定義您的應用程式將使用的資料結構。
在本文中，我們將探討 Tim 的方法，根據他的視頻中的準確解釋和範例設計錦標賽追蹤應用程式的資料。 我們將深入了解應用程式設計的主題，使用 Tim 的視頻來理解為什麼資料設計很重要以及它如何影響整個應用程式。
為什麼資料優先
Tim 在課程開始時提醒我們，我們已確立了應用程式的需求和結構。 現在是時候構建真正的資料結構了。 他指出，有些開發者喜歡先設計用戶介面，但他認為最成功的做法是先設計資料。
Tim 解釋了他的理由：
"沒有資料，應用程式就一無是處。" 他澄清說，應用程式本質上是一種用於顯示、操作、修改和保存資料的工具。
然後他給出了例子來證明他的觀點。 即使是像 Microsoft Word 這樣的文字編輯器也圍繞資料構建——文本本身、格式、間距等。Tim 更深入地指出，即使是遊戲也是基於資料的。 例如，象棋遊戲只是一堆棋子、位置和移動——都是資料。 第一人稱射擊遊戲也在很大程度上依賴於資料，如角色位置、子彈速度、命中檢測、傷害值和勝利條件。
他的結論很明確：
"一切都圍繞著資料。"
因此，他從資料設計開始，因為一旦您了解資料，用戶介面就會變得更容易構建。 否則，您就是在從一個空白的起點進行設計，毫無方向。 這種方法幫助那些使用視覺套件、海報製作工具或標誌製作工具的開發者和設計師，因為即使這些應用程式也依賴於結構化資料來創建模板、字體和圖像元素。
編碼前的規劃
然後，Tim 解釋了他偏好的規劃方法： 他會在紙上或白板上畫出所有內容，因為這樣更容易更改和調整。
他強烈建議現在不要打開 Visual Studio，強調規劃應該在代碼之外進行。 他說，在記事本或法律信紙上規劃是必需的，因為您可以輕鬆刪除並進行更改，而不會被代碼困住。
Tim 展示了他的設計的清理版本並逐步講解。第一條規則是：
"只需寫下什麼。"
他從最明顯的對象開始：團隊。
構建團隊對象
Tim 開始設計，寫下團隊需要的內容。 他確定了兩個主要屬性：
1. 團隊成員
他指出，一個團隊需要人，因此他寫下了一些人的名單：
"我知道我需要一個有人的團隊。"
他解釋說，他還不需要建立 Person 對象。 相反，他專注於團隊，並寫下了一個便條來創建一個 Person。 這樣可以保持設計的重點，避免失去主對象的跟蹤。
2. 團隊名稱
接下來，Tim 將團隊名稱添加為字符串。
他解釋說，團隊類很簡單，只需一些關鍵屬性。 他說團隊名稱應當是一些像"Tim Bob Maris Su Al"或"乒乓錦標賽"這樣容易記住的東西，這有助於品牌和識別，類似於商業如何使用標誌、品牌或公司名稱。
設計人員對象
接下來，Tim 設計了 Person 類。 他解釋了將名字和姓氏分開的重要性。
為什麼要分開名字和姓氏？
Tim 說這是業界的最佳實踐，有助於個性化處理，例如在電子郵件中用名字稱呼某人。
他還警告了名字拆分問題：
"Van Wilder"不是"Wilder"
"Mary Sue"不是"Mary"
因此，Tim 強調應該在輸入階段分開名字和姓氏，而不是後期拆分。
其他屬性
Tim 添加了更多字段：
電子郵件地址（字符串）
手機號（字符串）
他強調手機號應該作為字符串存儲，因為它們不是要計算或操作的數字。 它們可能包括格式如括號和破折號。
Tim 也澄清他用到"屬性"這個詞，因為這些將成為 C# 中的類屬性。
錦標賽對象
然後，Tim 引入了最重要的對象：錦標賽。
他解釋說，錦標賽是中央資料中心，因為此應用程式是一個比賽追蹤程序。
錦標賽屬性
Tim 列出了錦標賽需要什麼：
-
錦標賽名稱 雖然這不是要求中的內容，他還是加上了，因為多個錦標賽可以同時存在。 名稱幫助區分它們。
-
入場費 Tim 解釋說，入場費允許管理員在團隊進入時收取費用。 他強調入場費必須存儲為十進位，而不是雙精度，因為這是錢。
-
參賽團隊 進入錦標賽的團隊名單。
-
獎品 獎品名單，可能是零或更多。
- 回合 這部分比較複雜。 Tim 解釋說，每一輪都包含對決，因此結構變成了一個清單的清單：
回合1：對決名單
回合2：對決名單
回合3：對決名單
因此，回合是 List
Tim 指出此時獎品和對決對象尚未創建，但這沒關係，因為它們將在稍後開發。
自然鍵與缺失的資料
Tim 警告您在規劃過程中會漏掉一些資料。 他談到了自然鍵，以及一些開發者如何使用它們作為標識符。 例如，錦標賽名稱可能是唯一的，可以作為標識符。
然而，Tim 更喜歡使用自定義的 ID 屬性：
"我喜歡創建自己的，稱之為 ID。"
他說這樣便於索引和管理。
他還提醒我們：
"遺漏資料是正常的。"
他鼓勵進行研究並查看像亞馬遜註冊或電話聯繫人之類的範例，以了解通常收集的是什麼信息。
但他警告不要過度思考——錯誤會發生，可以在以後修正。
不要過度規劃
Tim 強調了一個關鍵的平衡點：
"一個規劃得很好的應用程式仍在法律信紙上是無用的。"
他解釋說，規劃是必要的，但花太多時間在規劃上會妨礙您建造應用程式。 他鼓勵向前推進並接受設計的演變。
獎品對象
Tim 介紹了獎品對象及其屬性：
-
名次編號（int） 示例：1 表示第一名，2 表示第二名。
-
名次名稱（字符串） 示例："冠軍"、"亞軍"。
-
獎金數量（十進位） 該位置的金額。
- 獎品百分比（雙精度） 示例：0.5 表示 50%
他解釋了系統將如何根據哪個數量不為零來決定是用金額還是百分比。
對決對象
然後，Tim 介紹了對決對象：
-
項目：MatchupEntry 清單
-
優勝者：團隊
- 輪次編號：整數
-
他解釋說，對決項目代表對決中的一個團隊。
對決項目對象
Tim 描述了 MatchupEntry 屬性：
-
團隊
-
分數
- 父級對決
他解釋了為什麼他選擇一個項目清單而不是單獨的團隊屬性。 這樣可以提供靈活性，例如按分數排列項目。
他還解釋了父級對決的用途： 它將一輪的優勝者連接到下一輪。
結論 - 資料計畫完成
Tim 總結說，這六個類（團隊、個人、錦標賽、獎品、對決、對決項目）是應用程式的基礎。 他提醒我們資料計畫已經完成，下一課將重點研究構建用戶介面。
他最後說，雖然這種設計看起來可能很混亂，但一旦在碼中實現，將會變得更加清晰。
通過遵循 Tim 在視頻中的資料優先方法，您現在對於如何構建錦標賽追蹤應用程式的核心資料有了清晰的了解。 下一步是基於這些資料來構建 UI，Tim 在第四節課中涵蓋了這一內容。
免費開始使用
免費開始使用
預約免費現場演示
無需信用卡或創建帳戶
