Jak poprawnie tworzyć relacje w EF CodeFirst

Cześć,

Chciałem was zapytać drodzy koledzy, jak poprawnie tworzyć relacje pomiędzy tabelami za pomocą Entity Framework i Code First. Oto dwa scenariusze nad którymi się zastanawiam.

W pierwszym scenariuszu EF wygeneruje tabele z kolumnami o nazwach EmpolyeeId i Contact_ContactId

    public class Employee
    {
        public int EmployeeId { get; set; }
        public Contact Contact { get; set; }
    } 

W drugim scenariuszu EF wygeneruje tabele z kolumnami o nazwach EmpolyeeId i ContactId

    public class Employee
    {
        public int EmployeeId { get; set; }
        public int ContactId { get; set; }

        public Contact Contact { get; set; }
    } 

Wydaje mi się ze druga opcja jest poprawna, ponieważ właściwość public Contact Contact { get; set; } jest tylko właściwością nawigacyjną? (nie wiem czy nie pisze głupot teraz). No i nazwa kolumny jest trochę lepsza, ale z drugiej strony pierwszy scenariusz jest wygodniejszy.

Gdybyście mogli nie zjechać mnie za mocno i podpowiedzieć jak jest poprawnie i czy to ma w ogóle jakieś znaczenie, to byłbym wdzięczny :)

Dzięki!

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

  public virtual ICollection<Bar> Bars { get; set; }
}

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

  public int FooId { get; set; }
  public virtual Foo Foo { get; set; }
}

Rozumie że tak jest "pro" ;). Dzięki wielkie za szybką odpowiedź n0name!

Czy "pro" to nie mam pojecia. W kazdym razie ja tak robie oraz panowie i panie od MSu tez propaguja taki styl. ;P

czemu "virtual" ?

Bo w C# sie nie zrobi proxy bez virtual, a to jest do lazy potrzebne.

jeszcze jedno kontynuując, czy to jest poprawne?

public class Person
{        
    public int personId { get; set; }

    public string firstName { get; set; }

    public virtual IEnumerable<Person> Persons { get; set; }        
}

na jednym widoku chcę umieścić formularz do wprowadzania a poniżej listę wprowadzonych. Przykład banalny, ale czy poprawny jest model?

@n0name_l
Wzorując się na implementacji MS to brakuje jeszcze tego aby:
-kolekcje uzupełniać pustymi listami podczas tworzenia obiektu
-kolekcje nie powinny mieć publicznych setterów
Źródło: https://github.com/aspnet/Identity/blob/dev/src/Microsoft.AspNet.Identity.EntityFramework/User.cs

@szymon7500 http://dotnet.dzone.com/news/using-self-referencing-tables

@n0name_l dzięki za linka, trochę to pokręcone, ale z czasem to zrozumiem.

Zwykle wlasciwosci tez proponuje ustawiac jako virtual, zeby mozliwe bylo sledzenie zmian