App Logic Planning — A Deeper Look at Tim Corey’s Approach
In his C# App Start To Finish series, Tim Corey explains that building an application is not just about writing code. The real challenge lies in planning the app logic — how the different parts of the application will interact, communicate, and move data between screens and components. In Lesson 05 on Logic Planning, Tim focuses on logic planning, emphasizing that this is the stage where you decide how the application will behave as a whole.
He reminds us that up to this point, the course has already covered scoping requirements, building the overall structure, designing the data backend, and drawing out the front end. Now, Tim says, the next step is to connect everything through logic.
Tim clarifies that this lesson won’t dive into code yet. Instead, he wants to cover the global ideas, the big picture, and the overall logic behind the application. He encourages writing notes on paper and drawing arrows to map out how each form and button should behave, which is similar to how business processes are mapped in professional development environments. This planning helps the app logic become clear before moving into coding.
Why Logic Planning Matters
Tim begins by stating that wiring up forms is the major part of application logic. Once the forms are correctly connected, the remaining tasks are usually smaller. He explains that the logic planning process helps you understand the functionality, processes, and controls that the application must support.
Tim says that if he were doing this on paper, he would write down what each component should do and draw arrows between them. Even though the class is working on-screen, he plans to walk through each form and explain the logic behind each piece.
Create Tournament Form Logic
Tim starts with the Create Tournament form, which is one of the simpler forms. He explains the logic behind each button and how they should work together.
Create New Team Button
Tim explains that the Create New Team button opens the Create Team form. After a team is created, the new form closes and the created team data is returned to the Create Tournament form. The team should appear in the team/players list box, and this is done by creating a method that can be called from the Create Team form.
Tim also introduces the concept of using interfaces for this communication, explaining that interfaces allow forms to interact without knowing about each other directly. This is a classic example of how business logic and software architecture work together to maintain quality, integrity, and clean interaction between components.
Add Team Button
Tim explains that the Add Team button is straightforward. It checks which item is selected in the dropdown, adds that team to the tournament list, removes it from the dropdown, and then refreshes both lists. This logic ensures that the user’s selection is reflected correctly in the UI and the underlying data.
Create Prize Button
Tim explains that the Create Prize button behaves similarly to the Create New Team button. It opens the Create Prize form, waits for the prize to be created, and then adds that prize to the prizes list box. The logic is the same, but the class and data type are different.
Delete Selected Buttons
Tim explains that the delete buttons remove the selected item from the list box. In the case of teams, the logic also returns the deleted team back to the dropdown list, ensuring the user can add it again later. This type of real time update improves user experience and helps maintain correct data across the UI.
Create Tournament Button
Tim explains that this is the big button because it triggers the most logic. When clicked, it must validate all information:
Tournament name must not be empty
Entry fee must not be negative
- At least two teams must exist
After validation, Tim explains the next major step: creating the schedule. The tournament schedule logic determines how many teams should be in the tournament and how many byes are required. Tim references a companion document where he wrote the formula for this calculation. For example, if the tournament has 10 teams, the tournament must start with 16 teams, meaning 6 byes are needed in the first round.
Tim also notes that the logic needs to randomize the order of the first round. Once all this is complete, the form is finished and the application can move forward.
Create Team Form Logic
Tim moves on to the Create Team form and explains the logic behind its buttons.
Add Member Button
Tim says this button adds an existing member from a dropdown list to the team list box. It then removes that member from the dropdown and refreshes both lists. Tim highlights that this is similar logic to the Add Team button.
Create Member Button
Tim explains that the Create Member button takes the four input fields, creates a new team member, adds them to the list box, and clears the fields. This is a typical example of common tasks in application logic, where user input must be processed and reflected in the UI.
Create Team Button
Tim says the Create Team button must validate the team and then send the created team back to the caller. He notes that the form is missing a delete player button, which should be added to match the other forms and provide consistent user experience. Tim explains that consistent UI behavior is important for user familiarity and comfort.
Create Prize Form Logic
Tim describes the Create Prize form as simpler. It has four text boxes and one button.
When the Create Prize button is clicked, it:
Validates the prize information
Sends the data back to the calling form
- Closes the form
Tim explains that this form is essentially the same as Create Team but with fewer components.
Tournament Dashboard Logic
Tim explains the Tournament Dashboard form as simple but essential.
It lists existing tournaments. The Load Tournament button opens the Tournament Viewer for the selected tournament, and the Create Tournament button opens the Create Tournament form.
Tim notes that when a tournament is created, it should be added to the dropdown list, so the user can immediately load it. This logic is a basic example of data access and real time updating within an app.
Tournament Viewer Logic
Tim describes the Tournament Viewer as the most complex form because it contains the most logic.
Tournament Name
Tim explains that the tournament name is updated when the form loads. The form receives a tournament object and displays the name.
Rounds Dropdown
Tim explains that this dropdown is calculated, not loaded from a database. It looks at the list of rounds and determines how many exist. If a tournament has four rounds, the dropdown must display Round 1 through Round 4.
Unplayed Only Checkbox
Tim says that if the checkbox is checked (default), the matchup list box is filtered to show only unplayed games. If unchecked, all matchups appear.
Matchup Score Section
Tim explains that selecting a matchup updates the right-side section with team names and scores. The Score button allows the user to update scores and finalize the matchup.
Triggering Next Round
Tim explains that when the last unplayed matchup in a round is scored, the next round should start. If it’s the final championship game, the tournament ends and prizes are assigned. Tim also notes that the system sends emails to participants when they are scheduled to play and when results are available.
Score Editing Rules
Tim asks whether scores can be updated after they are set. He concludes that yes, but only while the current round is still active. If scores are changed after the next round has started, it could cause major issues because teams might play the wrong opponents.
Therefore, Tim says the Score button needs logic to ensure the score can only be changed in the current round.
What’s Next?
Tim acknowledges that some logic still needs to be planned, such as:
Data access and storage
Handling different data sources
Email logic
- Triggering matchups
He says these are better planned inside the code, so the team will tackle them once they start coding. This is an example of business integrity in software development — not overplanning, but building and adapting as you implement.
Conclusion: Planning Before Coding
Tim concludes his video by stating that the planning phase is complete:
Data design is finalized
UI layout is drawn
- Logic behind each form is planned
The next step is to translate this into code. In the next lesson, Tim will create the class library and begin implementing the data design into the actual application.
Get started for FREE
Get started for FREE
Book Free Live Demo
No credit card or account creation required
