具有两个指向彼此的表的实体框架注释

Question

I am trying to use CodeFirst to generate my database.

I have two tables Staff and Team , There is one Team Leader in each team that is a foreign key to a staffID, and each staff is associated to one Team.

public class Staff
{
    [Key]
    public int ID { get; set; }
    public string Name { get; set; }
    public string Username { get; set; }
    public string PasswordHash { get; set; }
    public string Salt { get; set; }
    public string Token { get; set; }
    public string Mobile { get; set; }
    public string Email { get; set; }
    public bool Admin { get; set; }
    public bool Active { get; set; }

    public int TeamID { get; set; }

    [ForeignKey("TeamID")]
    public Team Team { get; set; }
}

public class Team
{
    [Key]
    public int ID { get; set; }
    public string Name { get; set; }
    public int TeamLeaderID { get; set; }

    [ForeignKey("TeamLeaderID")]
    public Staff TeamLeader { get; set; }
}

Because each one is pointing to the other I get an error Unable to determine the principal end of an association between the types 'Team' and 'Staff'. The principal end of this association must be explicitly configured using either the relationship fluent API or data annotations. Unable to determine the principal end of an association between the types 'Team' and 'Staff'. The principal end of this association must be explicitly configured using either the relationship fluent API or data annotations. How do I annotate it in such a way that it understands why I am doing this.

Answer 1

Think about it this way... what comes first the team or the team leader? If you try to create a team leader you can't because you have to first specify a team! But if you want to create a team you can't because you must specify who the team leader is according to your foreign key constraints.

You will have to ease up in some way and either make it so that a team can have an optional team leader, or a staff member can optionally belong to a team.

You do this by changing one of the foreign key IDs to a nullable type:

public int? TeamLeaderID { get; set; }

Answer 2

Your code seems like you are trying to include business rule enforcement/responsibility via referential integrity. You have a one to many relationship your Team -> Staff. You just add a boolean for the TeamLeader. Your logic before doing a database write should check to see if you have an existing TeamLeader or not already.

public class Staff
{
    [Key]
    public int ID { get; set; }
    public string Name { get; set; }
    public string Username { get; set; }
    public string PasswordHash { get; set; }
    public string Salt { get; set; }
    public string Token { get; set; }
    public string Mobile { get; set; }
    public string Email { get; set; }
    public bool Admin { get; set; }
    public bool Active { get; set; }
    public IsTeamLeader { get; set; }

}

public class Team
{
    [Key]
    public int ID { get; set; }
    public string Name { get; set; }

    //virtual keyword tells Code First to create the proper Foreign Key relationship 
    public virtual List<Staff> Members{ get; set; }
}

If you had a large system, with many developers, you could use the fluent API to accomplish your goal and enforce your team leader rule at the database level, thus preventing an out of touch developer from inadvertently adding a second team leader to any give team but if this is a small to normal size project, with small teams that are aware of the basics of the company/project than a simple one to many relationship will accomplish the mission and you can rely on your business rules/logic to enforce/protect the database data so that there is one team leader for any given team at any give time. Consider an AddUpdateTeamMember type method that is called by everyone that enforces the team leader requirement. A stored procedure is another great way to easily solve this problem if you are still considering a model first approach and still experimenting with code first.

Consider too, what if there was a need for two team leaders on one team at some future point of time in the project, database might get too inconveniently "locked down" to scale to this change.