Error with relationship - asp.net-mvc

Question

I have a User table and an Avatar table. One User can have many avatars (or null). But I need to mark which avatar is the current, so I have an Avatar_Id in User table that is the current avatar. And a ForeignKey User_Id in Avatar to tell me which User is the owner.
Trying to do that is generating me a lot of errors and headaches when I try to populate some data in order to test the relationship.
public class User
{
[Key]
public int Id { get; set; }
public Avatar Avatar { get; set; }
public virtual ICollection<Avatar> Avatars { get; set; }
}
public class Avatar
{
[Key, ForeignKey("User")]
public int Id { get; set; }
public User User { get; set; }
}
Test part:
var user = new User();
var avatar = new Avatar()
{
User = user
};
// user.Avatar = avatar; // <- this gives [a circular] error; without this I have null.
db.Users.Add(user);
db.Avatars.Add(avatar);
db.SaveChanges();
This is resulting me with Avatar_Id = NULL within User table, and User_Id = NULL in Avatar table. I expected these fields filled (well, Avatar_Id can be null).

Answer 1

Its better to make boolean field 'IsDefault' in table with avatar and check while add/update avatars that no more default avatars for this user. Also you can add same property in avatar class.

Answer 2

#Fabricio I can't test this code before post, but I'm pretty convinced it will work.
public class User
{
[Key]
public int UserId { get; set; }
public int AvatarId { get; set; }
[ForeignKey("AvatarId")]
public Avatar Avatar { get; set; }
public ICollection<Avatar> Avatars { get; set; }
}
public class Avatar
{
[Key]
public int AvatarId { get; set; }
[ForeignKey("User")]
public int UserId { get; set; }
public User User { get; set; }
}
The problem is when you put two foreign keys merge like one. Now you have a foreign key in Avatar table and other in User table, each one represents one mode of relationship.
The foreign key "AvatarId" represents a special form of foreign key, a unique + foreign key, (a second form to build the one to one relationship). You can read more about this in here: http://weblogs.asp.net/manavi/archive/2011/05/01/associations-in-ef-4-1-code-first-part-5-one-to-one-foreign-key-associations.aspx

Answer 3

I've given this a bit of though because I modeled a similar case once and didn't mind to reevaluate the options.
Look closely at your premises:
One User can have many avatars (or null)
This short sentence implies that the one-to-one association User-Avatar must be optional both ways, because a User without Avatars can’t possibly refer to one its own avatars, and when a user has more than one avatar only one of them can refer to User as being the user's default. (They all refer to user as owner).
So you can only model it as a 0..1 – 0..1 association. So Avatar’s primary key can't be a foreign key to user. (It couldn't anyway, otherwise a user could only have one avatar).
Maybe this could have been done by Jonny Piazzi's model if this wouldn't throw the infamous "may cause cycles or multiple cascade paths" exception. Both user and Avatar refer to one another and you have to tell EF explicitly which of the FKs is not cascading. This can only be done by fluent mapping:
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<User>()
.HasOptional(u => u.Avatar)
.WithOptionalDependent()
.Map(m => m.MapKey("AvatarId"))
.WillCascadeOnDelete(false);
...
}
This puts a nullable, non-cascading FK column AvatarId in User (that's why User is the dependent of Avatar).
Now your second issue, the chicken-eg problem when populating the model.
This can only be done when you call SaveChanges twice and wrap these calls in a transaction scope. For example:
using (var tran = new TransactionScope())
{
var user = new User();
var avatar = new Avatar();
user.Avatars = new HashSet<Avatar>();
user.Avatars.Add(avatar);
user.Avatars.Add(new Avatar());
user.Avatars.Add(new Avatar());
db.Users.Add(user);
db.SaveChanges();
user.Avatar = avatar; // set FK
db.SaveChanges();
tran.Complete();
}
Now EF can decide which key to generate first (User's) before referring to it by foreign keys. Subsequently you set the FK in User.
But... is this the best model?
Maybe, maybe not.
The issue is that your model does not enforce the business rule that a user can only have one of its own avatars as default avatar. User.AvatarId can refer to any avatar. So you have to write business logic to enforce the business rule.
With YD1m's solution (no User.AvatarId, but a column Avatar.IsDefault) this business rule is enforced implicitly. But now you have to write business logic to enforce that only one avatar is the default.
It's up to you to decide what you think is more feasible.
(for the record: way back, I took the latter option)