Utworzenie relacji pomiędzy tabelami

Witam, chciałbym utworzyć relacje pomiędzy tabelami w mojej aplikacji MVC. Korzystam z Entity Framework. Mam już prototyp jakby to miało wyglądać i chciałem prosić Was o opinie czy to będzie w ogóle działać, co mam zmienić.

W mojej aplikacji mam trzy klasy pomiędzy którymi chciałbym utworzyć relacje. Są to:

1. UserProfile

 
public class UserProfile
{
      public string UserID {get; set;}  //PK
      public string UserName {get; set;}
      public string FirstName {get; set;}
      public string LastName {get; set;}

      public virtual List<Service> Services {get; set;}

      public virtual List<VisitDetails> visitDetails {get; set;}
}

2. Service

public class Service
{
      public int ServiceID {get; set;}  //PK
      public string Name {get; set;}
      public string Category {get; set;}
      public string Description {get; set;}
      public decimal Price {get; set;}

      public virtual List<UserProfile> UserProfiles {get; set;}

      public virtual List<VisitDetails> visitDetails {get; set;}
}
 

3. VisitDetails

public class VisitDetails
{
      public int VisitID {get; set;}  //PK
      //public string LoginUser {get; set;} ?
      public string Date {get; set;}

      public int ServiceID {get; set;} //- ForeignKey
      public virtual Service service {get; set;}

      public int UserID {get; set;} //- ForeignKey
      public virtual UserProfile userProfile {get; set;}
}
 

Tak to wygląda graficznie.

Chodzi tutaj o rejestracje użytkowników. Zarejestrowany użytkownik(UserProfile) wybiera sobie usługę która mu odpowiada(Service), następnie wybiera termin i się na nią rejestruje(VisitDetails).

P.S proszę o wyrozumiałość.. Nigdy wcześniej tego nie robiłem.

Jeżeli się nie mylę to dla relacji wiele do wielu potrzebujesz trzeciej tabeli, która będzie zawierać oba klucze. Natomiast w relacji 1-1 możesz używać atrybutu przed propertem np: [ForeignKey("ServiceID")] jeśli PK oznaczyłeś atrybutem [Key]. Nie jestem natomiast tego pewien, bo dopiero co zacząłem interesować się tematem MVC, więc chętnie zweryfikuje swoją wiedzę i również proszę o wyrozumiałość.

Proponuję wczytać się w ten tutorial:
http://www.entityframeworktutorial.net/
Dużo pomaga, jest zwięzły i treściwy.

Cześć, tak na szybko (nie wgłębiając się w strukturę). W klasach zamiast List używaj ICollection za http://stackoverflow.com/questions/7655845/icollectiont-vs-listt-in-entity-framework.
Ponadto, na rysunku masz coś takiego jak

join table utworzona przez EF
. Staraj się raczej samemu tworzyć takie tabele / klasy, a nie powierzać tego zadania EF. Pamiętaj, że lepiej jest mieć pełną kontrolę nad tym co się robi.

MacGyver76 napisał(a):

Ponadto, na rysunku masz coś takiego jak

join table utworzona przez EF
. Staraj się raczej samemu tworzyć takie tabele / klasy, a nie powierzać tego zadania EF. Pamiętaj, że lepiej jest mieć pełną kontrolę nad tym co się robi.

Sugerujesz, że EF jest zbyt tępy nawet na to, żeby utworzyć tabelę mapującą m:n z dwoma kluczami?

somekind napisał(a):

MacGyver76 napisał(a):

Ponadto, na rysunku masz coś takiego jak

join table utworzona przez EF
. Staraj się raczej samemu tworzyć takie tabele / klasy, a nie powierzać tego zadania EF. Pamiętaj, że lepiej jest mieć pełną kontrolę nad tym co się robi.

Sugerujesz, że EF jest zbyt tępy nawet na to, żeby utworzyć tabelę mapującą m:n z dwoma kluczami?

Sugeruję, żeby mieć wszystko pod kontrolą. Poza tym, jest to wygodne, kiedy zaglądasz w model i widzisz wszystkie klasy odpowiadające tabelom, a nie, że istnieją jeszcze jakieś inne magiczne tabele, o których istnieniu niekoniecznie wszyscy mają lub dopiero będą mieć pojęcie.

MacGyver76 napisał(a):

Sugeruję, żeby mieć wszystko pod kontrolą. Poza tym, jest to wygodne, kiedy zaglądasz w model i widzisz wszystkie klasy odpowiadające tabelom, a nie, że istnieją jeszcze jakieś inne magiczne tabele, o których istnieniu niekoniecznie wszyscy mają lub dopiero będą mieć pojęcie.

Model powinien być obiektowym odzwierciedleniem rzeczywistości, a nie definicją struktur danych w bazie. Istnienie dodatkowej tabeli mapującej to jest szczegół implementacyjny bazy danych, w modelu obiektowym są to po prostu kolekcja obiektów B w klasie A, i obiektów A w klasie B, i nie ma sensu tworzenie sztucznych tworów. Przy Twoim podejściu należałoby nie korzystać z ORMa w ogóle.

somekind napisał(a):

MacGyver76 napisał(a):

Sugeruję, żeby mieć wszystko pod kontrolą. Poza tym, jest to wygodne, kiedy zaglądasz w model i widzisz wszystkie klasy odpowiadające tabelom, a nie, że istnieją jeszcze jakieś inne magiczne tabele, o których istnieniu niekoniecznie wszyscy mają lub dopiero będą mieć pojęcie.

Model powinien być obiektowym odzwierciedleniem rzeczywistości, a nie definicją struktur danych w bazie. Istnienie dodatkowej tabeli mapującej to jest szczegół implementacyjny bazy danych, w modelu obiektowym są to po prostu kolekcja obiektów B w klasie A, i obiektów A w klasie B, i nie ma sensu tworzenie sztucznych tworów. Przy Twoim podejściu należałoby nie korzystać z ORMa w ogóle.

https://skillsmatter.com/skillscasts/5688-orms-you-re-doing-it-wrong
Proszę obejrzeć od 13:25.

W skrócie oprócz braku "magicznej" tabeli są też względy wydajnościowe + możliwość dodania pola bezpośrednio do tego obiektu. Na przykładzie EF.

MacGyver76 napisał(a):

https://skillsmatter.com/skillscasts/5688-orms-you-re-doing-it-wrong
Proszę obejrzeć od 13:25.

W skrócie oprócz braku "magicznej" tabeli są też względy wydajnościowe + możliwość dodania pola bezpośrednio do tego obiektu. Na przykładzie EF.

1. Istnienie magicznej tabeli nie jest żadną wadą. Po prostu, w określonym przypadku oczywiste jest, że taka tabela powstanie, nie ma tu żadnej magii.
2. To, że EF powoduje jakieś problemy wydajnościowe, to nie jest żaden argument przeciwko automatycznemu mapowaniu, co najwyżej przeciwko EF.
3. Możliwość dodawania pól... to jest szczyt hipokryzji. Bogard sam chwilę wcześniej mówił o YAGNI, a teraz nagle chce tworzyć klasy, bo może kiedyś w przyszłości coś do nich trzeba będzie dodać.

somekind napisał(a):

1. Istnienie magicznej tabeli nie jest żadną wadą. Po prostu, w określonym przypadku oczywiste jest, że taka tabela powstanie, nie ma tu żadnej magii.
2. To, że EF powoduje jakieś problemy wydajnościowe, to nie jest żaden argument przeciwko automatycznemu mapowaniu, co najwyżej przeciwko EF.
3. Możliwość dodawania pól... to jest szczyt hipokryzji. Bogard sam chwilę wcześniej mówił o YAGNI, a teraz nagle chce tworzyć klasy, bo może kiedyś w przyszłości coś do nich trzeba będzie dodać.

1. Zdecydowanie nie jest oczywiste. Jest nieintuicyjne dla początkującego programisty, natomiast w dużych komercyjnych projektach nie ma miejsca na zabawy w postaci "ORM gdzieś sobie tam coś wygeneruje".
2. Moim zdaniem warto jest przemyśleć kwestię możliwości dodawania pól do klasy, w szczególności tych mapowanych na tabelę BD - oczywiście, nie wszystko da się przewidzieć, ale mieć taką możliwość jest zdecydowanie lepsze niż jej nie mieć. Sam się o tym nie raz przekonałem.

Świetny Orzeł napisał(a):

1. Zdecydowanie nie jest oczywiste. Jest nieintuicyjne dla początkującego programisty

Jeśli wiadome jest, że korzystamy z ORMa, i wiadome jest, że klasa A ma kolekcję B, a B ma kolekcję A, to oczywiste jest, że powstanie tabela mapująca. Jeśli ktoś tego nie wie, to on ma braki w wiedzy, ale to nie zmienia faktu, że dla programisty jest to oczywista sprawa.

natomiast w dużych komercyjnych projektach nie ma miejsca na zabawy w postaci "ORM gdzieś sobie tam coś wygeneruje".

Zadaniem ORMów generalnie jest generowanie czegoś, wniosek - w dużych komercyjnych projektach nie ma miejsca na ORMy.

3. Moim zdaniem warto jest przemyśleć kwestię możliwości dodawania pól do klasy, w szczególności tych mapowanych na tabelę BD - oczywiście, nie wszystko da się przewidzieć, ale mieć taką możliwość jest zdecydowanie lepsze niż jej nie mieć. Sam się o tym nie raz przekonałem.

Jeśli trzeba przechowywać dodatkowe dane, to oczywiste, że trzeba stworzyć klasę. Ale jeśli ma pełnić tylko funkcję mapującą, to zgodnie z YAGNI tworzenie takiej klasy jest niepotrzebną pracą na wyrost.

Ciekawa dyskusja się rozwinęła, fajnie było poczytać ;) Nikt mnie nie wyśmiał za mój ERD, za klasy również czyli chyba jest okej. Zmienię tylko List na ICollection. Dzięki za pomoc ;)