Jak podchodzicie do tematu z encją, która ma liste różnych basetypow w EF Core?

Chodzi mi o sytuację, że macie jakaś klasę, która ma listę rożnych dervied classes. Np.:

public class Zamowienie
{
    public List<Produkt> Produkty {get;set;}
}

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

 public class Ksiazka : Produkt { ..}
 public class Zabawka : Produkt { ...}

 etc.

Przykład może mało sensowny jednak chodzi o samą idee, encja Zamowoienie posiada listę innych encji, które mogą być różnymi typami.
Korzystacie z dobrodziejstw EF czyli TPH/TPT czy może w samej encji Zamowienie robicie listę stringow, które będą wcześniej zserializowanymi produktami, czy może jest jeszcze jakieś inne podejście niż te 3 do tego tematu?

Jak dla mnie to to jest zbyt "statyczne" rozwiązanie. Produkt powinien mieć typ jako identyfikator kategorii, które powinny być słownikowe. Co zrobisz jak dojdzie inny typ produktu? Będziesz klepał nową klasę? Może ja nie rozumiem, ale to jest bardzo dziwne co próbujesz osiągnąć.

Chyba rozumiem już o co tobie chodzi. Ogólnie takie rzeczy rozwiązałbym słownikiem ProductType

public class Product
{
  public int Id {get;set;}
  public string Name {get;set;}
  public string Ean {get;set;}
  public int ProductTypeId {get;set;} // car, motorcycle, kredyt, pożyczka, książka, zabawka
  public bool IsActive {get;set;}
}

public class ProductType // klasa elementów tabeli słownikowej
{
  public int Id {get;set;}
  public string Name {get;set;}
  public bool isActive {get;set;}
}

Tobie chodzi o to, że główny model ma właściwości, który każdy typ produktu ma np.: Id, Name, isActive, a typowany model może mieć dodatkowo właściwości związane stricte z typem obiektu np.: EngineType, ISBN, Color. To już będzie musiał ci pomóc ktoś mądrzejszy ode mnie, albo może link z dokumentacji ciebie nakieruje na jakieś rozwiązanie. Ogólnie mówiąc, musisz mieć te wszystkie kolumny w tabeli w bazie. Nie mam pojęcia czy EF pozwala na dynamiczne generowanie kolumn/tabel na podstawie generycznych klas.

Styk obiektowo relacyjny dla hierarchii klas ma (chyba zawsze) ze trzy-cztery możliwości rozwiązania
Mapped Superclass, Table per Class, Single Table, Joined
https://thorben-janssen.com/complete-guide-inheritance-strategies-jpa-hibernate/

To nie kwestia języka, ale zdrowego rozsądku, więc wybaczcie w C# cytat ze świata Javy. Ten świat obiektowo-relacyjny znam lepiej.

Przykładowo nawet w aplikacji bankowej klient może mieć różne produkty, także też będzie przykładowy obiekt Client mieć listę typów Produkt po których będą dziedziczyć np. Kredyt, Pożyczka itp. Może ja czegoś nie widze i takie modele da się jakoś inaczej stworzyć niż w ten sposób? Będę wdzięczny za każdą wskazówkę jak do takich problemów podchodzić. — CSharpBeginner dziś, 09:41

Produkty bankowe jedynie rozsądne co mi się wydaje, dziedziczyć do grup: kredyt, rachunek operacyjny, lokata. A konkretny kredyt to tylko konfiguracja ogólnego kredytu.
I tyle dziedziczenia. Klasa kredyt ciągnie za sobą tematy zabezpieczenia, klasa Lokata tematy podatku Belki, klasa RachunkuPłatniczego (w tym karty) integrację z rzeczywistym realizatorem operacji. To są duże grupy zagadnień, i dziedziczenie to dobrze odzwierciedla.

Za 5 lat się pojawi (w trakcie rozwoju banku) klasa RachunkuInwestycyjnego, i to tyle dziedziczenia. Hierarchia klas jest relatywnie zamknięta i wolno zmienna.

Wszystko inne to nie dziedziczenie (jest, jabłko jest owoc), a relacja posiadania (kompozycja), np posiadanie konkretnej konfiguracji "kredyt za zero złotych ze zdjęciem Lewandowskiego"

To jest tylko przykład bardziej chodzi o idee. Dam inny, np. mamy klasę Person, który ma listę Vehicles. Po Vehicles może dziediczyć wiele klas jak Car, Motorcycle itp., każda z nich ma różne atrybuty/pola. Jak podejść do utworzenia encji dla takiej klasy? I jak zapisywać. — CSharpBeginner 2022-04-02 22:26

Nigdy.

Niestety, mapowanie obiektowo relacyjne to z istoty zagadnienia znaczny problem, tam nie ma samego miodu.
Trzeba z góry podporządkować myślenie projektowe.
W szczególności nie dziedziczyć po szkolnemu.

W zamówieniu trzymasz kolekcje interfejsików IProdukt, pod spodem zapisujesz produkty do bazki jako json z pomocą customowego konwertera, który wie jaki sposób deserlizować odpowiedni produkt, albo korzystasz z https://github.com/manuc66/JsonSubTypes.

@ZrobieDobrze: "Równie dobrze można całą hierarchię w JSONie? Bo dlaczego nie?" Jeżeli adresuje to problem, który rozwiązujemy to jak najbardziej, nazywa się to document-oriented database. Polecam się zapoznać, dosyć popularne podejście. — sharper_99 dziś, 13:08

Ciekawy ten ton wyższości. Przypomnę, że wątek mówi o encjach a nie dokumentach.

Na marginesie, o ile współtworzę czy eksploatuję liczne bazy SQLowe (w tym bardzo poprawnie rozwiązujące zagadnienia dziedziczenia), nie mam w zasięgu wzroku autentycznie produkcyjnej bazy dokumentowej. Tym niemniej moja prosta inżynierska intuicja mówi, że niejedno g**no da się przypudrować w schemaless bazie dokumentowej.

Że w projekcie relacyjnym "da się" przypudrować elementarne braki projektowe przez JSONa - oczywiście że się da. Może architekt bazy nie żyje, albo co gorsza, żyje, tylko ma kiepskie wyniki z cholesterolu, może został członkiem (np zarządu) i nie należy mu przeszkadzać pytaniami od juniorów ...
Do pudrowania - bardzo wygodna konfiguracja - zgadzam się z @Miang

"Równie dobrze można całą hierarchię w JSONie? Bo dlaczego nie?" Jeżeli adresuje to problem, który rozwiązujemy to jak najbardziej, nazywa się to document-oriented database. Polecam się zapoznać, dosyć popularne podejście. — sharper_99 dziś, 13:08

Nie pracuję przy tym, ale było mi pokazywane. Paliwa.
Rządówka, dawny pion celny, obcenie zmienił nazwę.

Uszczelniamy mafię paliwową, prawda? Tak telewizor mówił.

Każda cysterna w ruchu hurtowym która rano wyjeżdża, już obciąża przypisanego odbiorcę paliwa na swoje 7tys albo 20tys litrów. Od tej pory planowany odbiorca jeszcze nie wie, ale juz zostaje mafiozem paliwowym.
Cysterna jedzie, ale zrzuca do zbiornika odbiorcy mniej, np tyle, ile dziś jest potrzebne.
Rzeczywisty zrzut paliwa się ... wpisuje jako komentarz w polu tekstowym "zatankowano 3723.5 litra"
Przyznasz @sharper_99 że bardzo elastyczne ? Pracowaliście przy tym?

Ciśniecie się niepotrz3bnie. Czasem json w polu db wystarczy ale raczej nie jako przechowywanie głównych danych encji. Ja mam np. Konfigurację protokołów komunikacyjnych w jsonie. Maszyna ma info o wersji protokołu A cały konfig jest w jsonie.

Ja osobiście nie widziałem nigdy prawdziwej aplikacji z tph w db. Ale ja mało widziałem. Chyba sam silnik db też powinien cośtam umieć
Zwykle się to jakoś abstrakcjonuje, jak @AdamWox napisał. Jakis typ encji. Jakies dodarkowe kilka pol w tabeli dla różnych typów albo osobną tabela z opcjami.

tedy ci panie Michale nie powiem, że hetman się o Waszmość pytał

https://docs.microsoft.com/en-us/ef/core/modeling/inheritance?msclkid=73912f38b3e711eca0f144f5d2623066

Z frajdą odnajduję idealnie ten sam podkład teoretyczny co w Javie.
Lekko *) zdzwiony że zaimplementowanie w miarę pełnego zestawu wariantów nastąpiło stosunkowo niedawno.

*) nie tak lekko zdzwiony tak naprawdę, ekosystem Javy to od dawna trawił