Currently I'm working on an application that operates with the following entities:
- Football Matches
- Teams
And I am dealing with a dilemma: How to represent the FootballMatch domain entity, which of these options is the most suitable? Also, a football match has score.
class FootballMatch
{
public Team FirstTeam { get; set; }
public Team SecondTeam { get; set; }
public DateTime Date { get; set; }
public string Score { get; set; } // like 0 - 3 (FirstTeam - SecondTeam)
}
or
class FootballMatch
{
public IEnumerable<Team> Teams { get; set; }
public DateTime Date { get; set; }
public string Score { get; set; } // like 0 - 3 (Teams[0] - Teams[1])
}
or (I think this is the best one, change my mind)
public class TeamPlay
{
public Team Team { get; set; }
public FootballMatch Match { get; set; }
public int Goals { get; set; }
}
public class FootballMatch
{
public TeamPlay FirstTeam { get; set; }
public TeamPlay SecondTeam { get; set; }
public DateTime Date { get; set; }
}
Any guidance / advice will be greatly appreciated! I don't know if it is ok to have a collection of teams if there will always be only 2 football teams playing a football match.
Please, note that I would like the Team to have a list of played FotballMatches
public class Team
{
public string Name { get; set; }
public IEnumerable<FootbalMatch> AttendedMatches { get; set; }
}
CodePudding user response:
I would recommend option 1:
class FootballMatch
{
public Team FirstTeam { get; set; }
public Team SecondTeam { get; set; }
public DateTime Date { get; set; }
}
The reason is that you know for sure that there will always be exactly two teams in a match. I understand the reluctance to have the teams be "ordered" even though the order does not really matter, but this design nevertheless corresponds most closely with the actual domain.
Additionally, this will make your life much easier in terms of db table design. You do not want to split the match
table into a match
and a match_teams
table. This will greatly reduce DB performance and make it overall harder and less efficient to query the data. It also opens the door to entries in the match_teams
table that associate more or less than exactly two teams per match.
In fact, I would recommend to make both team_id
fields non-nullable. This way you enforce that a match will consistently always have exactly two teams.
It is true that for querying all matches of a team (as presented in your third code snippet), your query will now have to cover two foreign key fields into the teams table (e.g. team1_id
and team2_id
). Nevertheless it is cleaner and more performant.
UPDATE
With regards to score keeping, I would recommend two numeric score fields on the same match
table that correspond to the two teams, i.e.: team1_id
, team2_id
, score1
and score2
. The same design can be applied to the corresponding domain object, which could look something like this:
class Match
{
public Team Team1 { get; set; }
public Team Team2 { get; set; }
public short Score1 { get; set; }
public short Score2 { get; set; }
public DateTime Date { get; set; }
//Stadium, Location, etc.
}