Entity Framework Code First Mapping Foreign Key Using Fluent API

30,439

Solution 1

I would personally move the Foreign Key relation from User to Address, and add an IsDefaultAddress property on the address class.

public class Address
{
    public int Id { get; set; }

    // This property marks the FK relation
    public virtual User User { get; set; }

    public string Name { get; set; }
    public string Details { get; set; }
    public virtual Area Area { get; set; }

    // This property signals whether this is the user's default address
    public bool IsDefaultAddress { get; set; }
}

EF will know that it needs a Foreign Key relation between Address and User.

This would simplify your model a great deal. That is, of course, if an address can only belong to one user (as asked by Slauma in the comments).

Solution 2

Your original model in the question should work. You can test it quite easily:

  • Create new console application (VS 2010)
  • Name it "EFTestApp"
  • Add reference to "EntityFramework.dll"
  • Delete content of Program.cs and copy the following code into the file

Program.cs:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ComponentModel.DataAnnotations;
using System.Data.Entity;

namespace EFTestApp
{
    public class User
    {
        public int Id { get; set; }
        public int? DefaultAddressId { get; set; }
        [ForeignKey("DefaultAddressId")]
        public virtual Address DefaultAddress { get; set; }
        public virtual ICollection<Address> Addresses { get; set; }
    }

    public class Address
    {
        public int Id { get; set; }
        public string Name { get; set; }
    }

    public class Context : DbContext
    {
        public DbSet<User> Users { get; set; }
        public DbSet<Address> Addresses { get; set; }
    }

    class Program
    {
        static void Main(string[] args)
        {
            using (var context = new Context())
            {
                try
                {
                    User user = new User() { Addresses = new List<Address>() };

                    Address address1 = new Address() { Name = "Address1" };
                    Address address2 = new Address() { Name = "Address2" };

                    user.Addresses.Add(address1);
                    user.Addresses.Add(address2);

                    context.Users.Add(user);

                    context.SaveChanges();
                    // user has now 2 addresses in the DB and no DefaultAddress

                    user.DefaultAddress = address1;
                    context.SaveChanges();
                    // user has now address1 as DefaultAddress

                    user.DefaultAddress = address2;
                    context.SaveChanges();
                    // user has now address2 as DefaultAddress

                    user.DefaultAddress = null;
                    context.SaveChanges();
                    // user has now no DefaultAddress again
                }
                catch (Exception e)
                {
                    throw;
                }
            }
        }
    }
}

In SQL Server Express it creates a new DB called "EFTestApp.Context". You can set breakpoints on every SaveChanges above, step over and watch the changes in the DB.

If you look at the relationships in the database then there are two, and in table Addresses in the DB is a foreign key column User_Id.

I think you could also remove public int? DefaultAddressId { get; set; } and [ForeignKey("DefaultAddressId")]. It creates the same database tables and relationships with an optional DefaultAddress.

Perhaps you want the relationship Address -> User as required (Addresses cannot live alone in the DB without a User). Then you can add this to the Context class:

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
    modelBuilder.Entity<User>()
                .HasMany(u => u.Addresses)
                .WithRequired();
}

It makes User_Id in the Addresses table non nullable and sets up cascading delete by default. So, when a user gets deleted all its addresses get deleted as well.

Solution 3

DefaultAddressId doesn't need any specific mapping because it will be just column in User table without any relation (FK) to Address table. There will be no relation created because navigation property doesn't exist on either side. Also it should be one-to-one relation which will not work because EF doesn't support unique keys.

I like solution provided by @Sergi Papaseit

Share:
30,439

Related videos on Youtube

Kassem
Author by

Kassem

Updated on March 31, 2020

Comments

  • Kassem
    Kassem about 4 years

    I have the situation where a User can have several addresses. Accordingly, I have an ICollection on my user class. But I also want the user to be able to choose a default address. So I've done the following:

    public class User 
    {
        public int Id { get; set; }
        public int? DefaultAddressId { get; set; }
        [ForeignKey("DefaultAddressId")]
        public virtual Address DefaultAddress { get; set; }
        public virtual ICollection<Address> Addresses { get; set; }
        //properties were removed for purpose of this post
    }
    

    I would like to remove the public virtual Address DefaultAddress { get; set; } altogether, keep the DefaultAddressId and map it using the Fluent API instead because the current setup is causing a lot of trouble (in this and other classes where I have a similar setup). So can this be done using the fluent api?

    UPDATE: The address class currently doesn't have any reference to the User class, it's a uni-directional relationship. But yes, an address belongs to only ONE user, it's not a many to many relationship. Here's the address class:

    public class Address
    {
        public int Id { get; set; }
        public string Name { get; set; }
        public string Details { get; set; }
        public virtual Area Area { get; set; }
    }
    
  • Kassem
    Kassem about 13 years
    How is EF supposed to know how to map it? Would it still be nullable? Because if a user hasn't yet added an address, this should be null and it shouldn't cause an error when adding the user to the database...
  • Kassem
    Kassem about 13 years
    @Sergi Papaseit: +1 for the answer. I do not know why I like complicating things. I should've done that right from the start. I guess I was obsessing about "normalization" of the database. I guess sometimes there has to be some compromise for the sake of simplicity. Thanks again :)
  • Kassem
    Kassem about 13 years
    Yeah I guess I'll just go with Sergi's answer. But do you suggest that I should add a navigational property back to User from the Address class?
  • Sergi Papaseit
    Sergi Papaseit about 13 years
    @Kassem - It's always good to keep K.I.S.S and YAGNI in mind ;) Happy to help :)
  • Ladislav Mrnka
    Ladislav Mrnka about 13 years
    Follow @Sergi's approach you will need just Addresses collection in User.
  • Slauma
    Slauma about 13 years
    Honestly I would go with the solution in the question. I don't know why it shouldn't work (I had just tested it and it's fine. It creates 2 relationships.) With your solution, one has to make sure in business logic that IsDefaultAddress isn't set on more than one Address of a user. And if you change the DefaultAddress one has to search for the old address and reset the old flag. The solution in the question expresses the "natural" relationships of the model better in my opinion and one doesn't need to worry about duplicate default flags.
  • Sergi Papaseit
    Sergi Papaseit about 13 years
    @Slauma - I must say, you do have a good point. My initial gut feeling would have been to do as I suggested, but it's true that having a DefaultAddress property in the User class expresses the relationship clearly. I guess it all depends on what you want to express/achieve. I would still add a reference to User in the Address class though.
  • Kassem
    Kassem about 13 years
    @Slauma: This is actually why I went with the solution in the question. I did not want to worry about duplicate default addresses which might be caused by Sergi's solution. But, I donno, I want to keep things as simple as possible in order to track down what's causing problems in my model. But naturally, if I add a reference to the User in the Address class, it should work fine?
  • Slauma
    Slauma about 13 years
    @Kassem: I've added a test example in an answer here. You can try that out and should see that it works with your simple model in the question. Maybe it helps you to find the problems you are having in your "real" model by comparing the two models and their configuration.
  • Sergi Papaseit
    Sergi Papaseit about 13 years
    You can also use the [Required] attribute on Addresses in the User class to mark the relation as required (EF will add an On Delete cascade as well). I'm not sure how that'll work on a collection though.
  • Slauma
    Slauma about 13 years
    @Sergi Papaseit: Yes, I tried that too to place the [Required] attribute on the Addresses collection but it doesn't work. There is no compiler error or EF exception, the foreign key simply stays nullable, so we still have an optional relationship. I guess we would need to add a User property on the Address class and then mark this property as [Required] if we wished to use DataAnnotations exclusively and no Fluent API.
  • Gats
    Gats about 13 years
    Yes it would still be nullable. I have found some problems mapping a 1 to 1 relationship using the fluent API as it doesn't seem to have a way to map a key to a specific column. In my case I've used 1 to many in the mapping even though the object only contains 1 instance of the child. That's done using HasOptional(u => u.DefaultAddress).WithMany().HasKey(u => u.DefaultAddressId);
  • ravi
    ravi over 12 years
    I am using this as well. But wondering if there is a way to avoid the intermediate savechanges before setting the default?
  • Slauma
    Slauma over 12 years
    @ravi: Did you test it to remove the first SaveChanges? It should work, doesn't it? The intermediate SaveChanges were only for debugging and demonstration purposes to show the changes in the DB.
  • ravi
    ravi over 12 years
    yes. I tried it and it does not work. It seems if the primary key is an incremental identifier than it does not know what the id of the default is without saving first. I think it would work if we use guid as the pk.

Related