Design App Data (Lesson 03) — A Deep Dive with Tim Corey
In this third lesson of the “C# App Start to Finish” course, Tim Corey takes us through the crucial step of data design. He explains that before you start building the user interface or writing code, you must first define the structure of the data your application will use.
In this article, we’ll explore Tim’s approach to designing the data for a tournament tracker application, following his exact explanations and examples from the video. We’re going to have a deeper look at the topic of app design, using Tim’s video to understand why data design matters and how it impacts the whole application.
Why Data Comes First
Tim starts the lesson by reminding us that we already established the requirements and structure for the application. Now it’s time to build the actual data structure. He points out that some developers prefer to design the UI first, but he believes the best success comes from designing data first.
Tim explains his reasoning:
“Your application is nothing without data.”\ He clarifies that an app is essentially a vehicle to display, manipulate, change, and save data.
He then gives examples to prove his point. Even a text editor like Microsoft Word is built around data — the text itself, formatting, spacing, etc. Tim pushes this further by showing that even games are data-based. A chess game, for example, is just a collection of pieces, positions, and moves — all data. A first-person shooter game also relies heavily on data like character positions, bullet speed, hit detection, damage values, and victory conditions.
His conclusion is clear:
“Everything revolves around data.”
So he starts with data design because once you know the data, the UI becomes easier to build. Otherwise, you’re designing from a blank slate with no direction. This approach helps developers and designers who work on tools like visual suites, poster makers, or logo makers, because even these apps rely on structured data to create templates, fonts, and image elements.
Planning Before Coding
Tim then explains his preferred method of planning:\ He draws everything on paper or a whiteboard because it’s easy to change and adjust.
He strongly recommends not opening Visual Studio yet, emphasizing that planning should happen outside of code. He says that planning in notepad or on a legal pad is essential because you can easily scratch things out and make changes without getting stuck in code.
Tim shows the cleaned-up version of his design and walks through it step-by-step. His first rule is:
“Just put something down.”
He begins with the most obvious object: Team.
Building the Team Object
Tim starts designing by writing down what a Team needs. He identifies two main properties:
1. Team Members
He notes that a team needs people, so he writes down a list of people:
“I know I need a team that has people in it.”
He explains that he doesn’t need to build the Person object yet. Instead, he focuses on the Team first and writes a note to create a Person later. This keeps the design focused and avoids losing track of the main object.
2. Team Name
Next, Tim adds the team name as a string.
He explains that the Team class is simple and only needs a few key properties. He says the team name should be something memorable like “Tim Bob Maris Su Al” or “Pingpong Tournament”, which helps with branding and identification, similar to how a business would use a logo, brand, or company name.
Designing the Person Object
Next, Tim designs the Person class. He explains the importance of breaking names into first and last names.
Why separate first and last name?
Tim says it’s best practice in the industry and helps with personalization, such as addressing someone by their first name in emails.
He also warns about name splitting issues:
“Van Wilder” is not “Wilder”
- “Mary Sue” is not “Mary”
So Tim emphasizes that separating first and last names should be done at the input stage, not by splitting later.
Other properties
Tim adds more fields:
Email address (string)
- Cell phone number (string)
He stresses that cell phone numbers should be stored as strings because they are not numbers to be calculated or manipulated. They may include formatting like parentheses and dashes.
Tim also clarifies that he uses the word “properties” because these will become class properties in C#.
The Tournament Object
Tim then introduces the most important object: Tournament.
He explains that the tournament is the central data hub, as this application is a tournament tracker.
Tournament Properties
Tim lists what a tournament needs:
Tournament Name\ Even though it wasn’t in the requirements, he adds it because multiple tournaments could exist at once. The name helps distinguish them.
Entry Fee\ Tim explains that an entry fee allows the administrator to charge teams when they enter. He stresses that the entry fee must be stored as decimal, not double, because it’s money.
Entered Teams\ A list of teams that have entered the tournament.
Prizes\ A list of prizes, which could be zero or more.
Rounds\ This part is complex. Tim explains that each round contains matchups, so the structure becomes a list of lists:
Round 1: list of matchups
Round 2: list of matchups
- Round 3: list of matchups\ So, Rounds = List
Tim notes that at this point, Prize and Matchup objects aren’t created yet, but that’s okay because they will be developed later.
Natural Keys and Missing Data
Tim warns that you will miss some data during planning. He talks about Natural Keys and how some developers use them as identifiers. For example, a tournament name could be unique and act as an identifier.
However, Tim prefers to use a custom ID property:
“I like to create my own and call it ID.”
He says it’s easier for indexing and management.
He also reminds us:
“It’s okay to miss stuff.”
He encourages doing research and looking at examples like Amazon sign-up or phone contacts to see what information is typically collected for a person.
But he warns not to overthink it — mistakes will happen and can be fixed later.
Don’t Over-Plan
Tim emphasizes a crucial balance:
“A well-planned application that’s still on your legal pad is useless.”
He explains that planning is necessary, but spending too much time planning can prevent you from ever building the application. He encourages moving forward and accepting that the design will evolve.
Prize Object
Tim introduces the Prize object and its properties:
Place Number (int)\ Example: 1 for first place, 2 for second.
Place Name (string)\ Example: “Champion”, “First Runner Up”.
Prize Amount (decimal)\ Money amount for that place.
- Prize Percentage (double)\ Example: 0.5 for 50%
He explains how the system will decide whether to use amount or percentage based on which one is non-zero.
Matchup Object
Tim then introduces the Matchup object:
Entries: List of MatchupEntry
Winner: Team
- Round Number: int
He explains that a matchup entry represents one team in a matchup.
Matchup Entry Object
Tim describes MatchupEntry properties:
Team
Score
- Parent Matchup
He explains why he chose a list of entries instead of separate team properties. This allows flexibility such as ordering entries by score.
He also explains the purpose of Parent Matchup:\ It links the winner from one round to the next round.
Conclusion - Data Plan Completed
Tim concludes that these six classes (Team, Person, Tournament, Prize, Matchup, MatchupEntry) are the foundation of the application. He reminds us that the data plan is complete and that the next lesson will focus on building the user interface.
He ends by saying that although this design might seem confusing, it will become clearer once implemented in code.
By following Tim’s data-first approach in the video, you now have a clear understanding of how to structure the core data for a tournament tracker application. The next step is to build the UI based on this data, which Tim covers in Lesson Four.
Get started for FREE
Get started for FREE
Book Free Live Demo
No credit card or account creation required
