Tournament Templates
One of the main parts of the program is to be able to put together any tournament format and then be able to run through thousands of tests to see the inherent bias of the tournament type. The tournament templates to be tested would then need to be anything from single elim, round robin, double elim, swiss, world cup rounds into single elim, etc. To achieve this, each tournament template would be a combination of TournamentTemplateMatches where each match accepts the 2 entering players from either the original player pool at the start of the tournament, another match previously held (Eg: single elim final match accepts the winners from the semifinals matches), a round robin subtournament, or an aggregator of previous scores to create a subtournament pool of ranked players.Because each match could be pointing back to another match or another round (I'm assuming that subtournament aggregators can be handled by the round template with no rounds), I needed a concrete way of storing which type it was. Setting the PreviousType to "Match"would also mean that the PreviousMatchID is now valid, whereas if "Round"was the previous type then the PreviousRoundID would be valid.
Enumerated Types in data first MVC
Ideally I'd like to see in the database the type listed so that the data is a bit more human readable, but after investigation it seems that C# prefers integers or Bytes as the underlying enumerator value. I'd debated changing them to integers, but decided to use bytes instead (Tinyint in SQL) so that they appear as a different type in not to be confused with an ID. Changing the database wasn't too hard after manually changing the data to conform, then updating the field type in the designer.Because I want to continually bring in database changes, I was keen to find a way that left the enumeration types already bound. I'd initially added the types in as another model, but found out later that you can add them directly into the model designer of the database with a right click > add > enum or by adding it to the enum types in the model browser. You can then change the fields to the new enumerated type. Doing this way it maintains the enum inside the database design (and scope) and also doesn't drop the assignment of the enum when the database is reloaded.
The display fields handled the enum perfectly, but the editing fields treated it like a string. There was some additional code to manually change the @html.EditorFor() to a @Html.EnumDropDownFor(), but I really wanted to be able to regenerate the controllers and views for any data first changes, so eventually settled on adding a html helper to overload the EditorFor() when an enum is detected.
