Golf Tracker - Final Wrap up
Well the application is finally finished, and I feel good about it. I fulfills all the requirements for the client and operates in a very fluid manner.I've had to rush and complete the entire application because of some commitments, so I'll go over what I've done in as much details as I can.
Refactor Golf Course Information
In order to make the changes necessary based on the new requirements I need to modify the database schema, and primarily add new information for golf courses to allow for storage of course rating, slope, tees, par, etc. As I mentioned before, by adding a new table called Tee, and joining it to the Course table, it will allow each golf course to have a one-to-many relationship with Tee which will in turn help the application be able to calculate the handicap index for a player when they post a score for a round of golf.This again will be the new database schema.
Now that this table is created, I can build a score posting form that looks like this.
But to get here, many things had to happen. I needed to completely modify the entire application from top to bottom to accommodate the new Tee table and some modifications to other entities, like Course and Round.
I also planned on building a custom API that will handle all the Round calculations. By having a specific project and class for this, I can easily maintain and updates to this without affecting much of the rest of the application.
Golf Score Posting
The primary thing I did to complete this application was to change the way the players handicap index is entered into the system. In a previous article I described how I built a custom ValidationAttribute class that allows a player to enter their handicap index into the system, but then validates it that if falls within a specific range. What this validation class does not do is validate that this is actually the players handicap index.So based on the new requirements by the client, there will be a different way of handling this and it's the logical way.
Do not allow the player to enter their own handicap index, but instead allow them to enter their score for a round of golf and then have the system perform some calculations that will dynamically figure out the handicap index for the player. This will of course prevent the player from cheating. It doesn't prevent the player from entering bogus scores to boost their handicap, but that's a different issue.
When the player fills out the score posting form, their score gets entered into the system so the RoundManagerAPI can act on it and perform any calculations necessary to manage a players handicap index. This is what the form may look like when it's filled out.
I've also built into the form some nice jQuery Ajax functions to populate the Course and Tee drop downs to give the user a nice experience. Once their score is entered into the system, calculations are executed and values are dropped into various tables for the player and score.
The details of a players rounds will look like this.
Now the Handicap Index is calculated on the fly when the page is requested from the best 10 of the last 20 scores. The player can now use this index to calculate their handicap when they go play a round of golf.
Conclusion
Using ASP.NET MVC 2, it was relatively easy to build and refactor the application to the client requirements. MVC also allowed for unit testing which helps make sure the application is always working as it should.I hope this exercise has given you some ideas in building your next MVC application.