設計應用程式資料（第03課）— 與Tim Corey的深度探討
[[academy-video-youtube({"vid": "I-lO-JhXrFQ", "start_time": "0", "title": "C# App Start To Finish Lesson 03 - Data Design", "creator": "Tim Corey", "length": "32m 01s"})]]
在"C#程式從開始到完成"課程的第三課中，Tim Corey 帶領我們進行關鍵的一步：資料設計。 他解釋說，在構建使用者介面或撰寫程式碼之前，您必須先定義您的應用程式將使用的資料結構。
在這篇文章中，我們將探討Tim設計錦標賽追蹤器應用程式資料的方法，跟隨他在影片中的詳細解釋和範例。 我們將深入探討應用設計的主題，使用Tim的影片來了解為何資料設計很重要，且如何影響整個應用程式。
為何資料優先
Tim以提醒我們已建立應用程式的需求和結構開始這堂課。 現在該建立實際的資料結構了。 他指出有些開發者偏好先設計使用者介面，但他認為最成功的方法是先設計資料。
Tim解釋他的理由：
"您的應用程式沒有資料什麼都不是。" 他澄清應用程式本質上是一種呈現、操作、改變和儲存資料的工具。
接著舉例證明他的看法。 甚至像Microsoft Word這樣的文書編輯器也是圍繞資料建構的——文字本身、格式、間距等。Tim更進一步顯示連遊戲也是以資料為基礎。 例如，象棋遊戲只是收集棋子、位置和移動——全部都是資料。 第一人稱射擊遊戲同樣依賴於資料，例如角色位置、子彈速度、命中檢測、傷害值和勝利條件。
他的結論很明確：
"一切都圍繞著資料。"
因此，他從資料設計開始，因為一旦您了解了資料，UI就會變得更容易構建。 否則，您就是從一個沒有方向的空白狀態開始設計。 這種方法幫助從事視覺工具、海報製作，或商標製作的開發者和設計師，因為即使這些應用也依賴於結構化資料來建立模板、字體和圖像元素。
編碼前的計畫
然後Tim解釋他偏好的計畫方法： 他將所有內容畫在紙上或白板上，因為這樣容易更改和調整。
他強烈建議尚未開啟Visual Studio，強調計畫應在程式碼之外進行。 他說，在記事本或筆記本上進行計畫是必要的，因為您可以輕鬆刪除並更改而不會陷入程式碼中。
Tim展示他的設計的清理版本並逐步講解。他的第一條規則是：
"就先寫點什麼。"
他以最明顯的物件開始：團隊。
構建團隊物件
Tim通過寫下團隊的需求來開始設計。 他識別出兩個主要屬性：
1. 團隊成員
他指出團隊需要人員，因此寫下一份人員清單：
"我知道需要一個有人的團隊。"
他解釋說目前不需要構建人員物件。 相反，他專注於團隊，並寫下筆記以後建立人員。 這保持設計專注且避免跟丟主要物件。
2. 團隊名稱
接下來，Tim將團隊名稱新增為字串。
他解釋團隊類很簡單，只需要一些關鍵屬性。 他說團隊名稱應是令人難忘的詞語，如"Tim Bob Maris Su Al"或"乒乓錦標賽"，這有助於品牌推廣和識別，類似企業使用商標、品牌或公司名稱的方式。
設計人員物件
接下來，Tim設計了人員類。 他解釋了將姓名拆分為名和姓的重要性。
為何分開名和姓？
Tim說這是業界的最佳實踐，有助於個性化，比如在電子郵件中按名字稱呼某人。
他還警告說姓氏分割問題：
"Van Wilder"不是"Wilder"
- "Mary Sue"不是"Mary"
所以Tim強調應在輸入階段分開名和姓，不要之後再分。
其他屬性
Tim新增了更多的字段：
電子郵件地址（字串）
- 手機號碼（字串）
他強調手機號碼應儲存為字串，因為它們並不是要計算或操作的數字。 它們可能包括格式，例如括號和破折號。
Tim還澄清他使用"屬性"這個詞，因為這些將成為C#中的類屬性。
錦標賽物件
然後Tim介紹了最重要的物件：錦標賽。
他解釋錦標賽是核心資料中樞，因為此應用是一個錦標賽追蹤器。
錦標賽屬性
Tim列出錦標賽的需求：
錦標賽名稱 儘管不在需求中，他仍加上因為可能同時存在多個錦標賽。 名稱有助於區分它們。
參賽費用 Tim解釋參賽費用允許管理者在參賽時向團隊收費。 他強調參賽費用必須作為十進位儲存而不是雙精度，因為它是金錢。
參賽團隊 一份參加錦標賽的團隊清單。
獎品 一份獎品清單，可能為零個或更多。
回合 這部分很複雜。 Tim解釋每個回合包含對陣，因此結構成為清單的清單：
第1回合：對陣清單
第2回合：對陣清單
- 第3回合：對陣清單 所以，回合 =
清單<清單>
Tim注意到此時尚未建立獎品和對陣物件，不過沒關係，因為他們將在之後開發。
自然鍵和遺漏資料
Tim警告在規劃中您會遺漏一些資料。 他談到自然鍵以及一些開發者如何使用它們作為識別符。 例如，錦標賽名稱可以是唯一的並作為識別符。
然而，Tim偏好使用自定義ID屬性：
"我喜歡建立自己的，稱之為ID。"
他說這對索引和管理更容易。
他還提醒我們：
"遺漏東西是可以的。"
他鼓勵做研究並查看亞馬遜註冊或電話聯絡人的範例，以了解一般收集什麼資訊。
但他也警告不要過度考慮——錯誤會發生，可以稍後修正。
不要過度規劃
Tim強調一個關鍵的平衡：
"一個計畫完善但仍在筆記本上的應用是無用的。"
他解釋計畫是有必要的，但花太多時間在計畫上會阻止您建造應用。 他鼓勵向前邁進並接受設計將會演化。
獎品物件
Tim介紹了獎品物件及其屬性：
名次數字（int） 範例：1表示第一名，2表示第二名。
名次名稱（字串） 範例："冠軍"、"第一亞軍"。
獎金金額（decimal） 該名次的金額。
- 獎金百分比（double） 範例：0.5表示50%
他解釋系統如何決定使用金額或百分比，依據哪一個是非零。
對陣物件
然後Tim介紹了對陣物件：
Entries：已對陣條目清單
贏家：團隊
- 回合編號：int
他解釋對陣條目代表對陣中的一個團隊。
對陣條目物件
Tim描述了對陣條目的屬性：
團隊
分數
- 父對陣
他解釋為何選擇用條目清單而不是獨立的團隊屬性。 這樣可以有彈性，例如按得分排列條目。
他還解釋了父對陣的目的： 它將一回合的冠軍連結到下一回合。
結論 - 資料計畫完成
Tim總結這六個類（團隊、人員、錦標賽、獎品、對陣、對陣條目）是應用程式的基礎。 他提醒我們資料計畫已經完成，下堂課將專注於構建使用者介面。
他結尾時說雖然這個設計可能看似困惑，但一旦實施在程式碼中就會變得清晰。
透過遵循Tim在影片中的資料優先方法，您現在對如何結構化錦標賽追蹤應用程式的核心資料有了明確的理解。 下一步是基於此資料構建UI，這在第四課中由Tim講解。
免費開始
免費開始
預訂免費直播演示
