public class Customer
{
public int CustomerId { get; set; }
public string MembershipId { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public string EmailAddress { get; set; }
}
public class Company
{
public string MembershipId { get; set; }
public string Name {get; set;}
}
public class CustomersBankAccount
{
public string Name {get; set;}
public int CustomerId { get; set; }
}
The convention when you want to build a database with code first convention is to have a "Id" (foreign key) part integrated in your properties.
Of course I recommend that all properties are declared virtual so that EF can grasp into your code and enable some features. like an efficient tracking mechnaism
So : If you have a property on the object named ID, EF assumes the property
holds the primary key value and sets up an auto-incrementing (identity) key column in SQL Server
to hold the property value.
Edit:
"On the object" meaning object of Customer. Essentially the primary key in your example is in customer , and the foreign key is in all other tables that are related to customer. A primary key cannot be duplicated or null. A foreign key - yes. It is possible that the same customer can have multiple bank accounts. :)
So if you are wondering , where is the plumbing to set your keys , stop. MVC can just look in the code above and decide (on a scaffolding selection) how to make the tabels in your DB. You don't have to indicate nothing in your code apart from what you allready seen (the "Id" an the end )
Edit based on my comment:
public class Customer
{
public int CustomerId { get; set; }
[Remote("CheckMembershipIdActionMethod", "CorrespondingController")]
public string MembershipId { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public string EmailAddress { get; set; }
}