Linq to Entites - Vererbte Entities

verwendetes Datenbanksystem: MSSQL mit LINQ to Entities

Hallo,

ich habe im Designer mir folgendes dbModel erstellt und daraus dann eine DB erzeugt (siehe angehängtes Bild).

Nun erzeuge ich diverse Angebote und speichere diese in die Datenbank. Soweit alles schick.

Doch nun bin ich an dem Punkt angelangt, an dem ein Angebot beauftragt und damit zu einem Projekt wird. Die Konvertierung eines Angebotes aus der Datenbank zu einem Projekt schlägt leider fehl (Typ 'PTool.Entities.Angebot' kann nicht in Typ 'PTool.Entities.Projekt' umgewandelt werden. 'LINQ to Entities' unterstützt nur die Umwandlung primitiver Entity Data Model-Typen.).

Wenn ich ein neues Projekt erstelle und die Daten aus dem Angebot kopiere erhalte ich - logischerweise - in der Projekttabelle den richtigen Eintrag aber in der Angebotstabelle das Angebot mit einer neuen ID nocheinmal.

Habt ihr eine Idee diesbezüglich? Kleiner Fehler? kompletter Holzweg?

Beste Grüße,
Chris

Hallo Motzi,

stellt die Überlegung mal rein OO-mäßig an. Dann gilt

public class Angebot {}

public class Projekt : Angebot {}

, also Projekt erbt von Angebot, also eine ist-eine-Beziehung. Und ein Projekt ist nun mal kein Angebot und somit ist dieses Design nicht passend.

mfG Gü

Hm,

danke erstmal für deine schnelle Antwort. Aber irgendwie steh ich grad noch aufm Schlauch.

Ich nehme einmal ein Beispiel:

public class Fahrzeug
{
string hubraum;
}

public class Motorrad : Fahrzeug
{
bool hatBeiwagen;
}

public class LKW : Fahrzeug
{
double groesseLadeflaeche;
}

Jedes Motorrad ist ein Fahrzeug (hat alle Fahrzeugeigenschaften plus eine eigene)
Jeder LKW ist ein Fahrzeug (hat alle Fahrzeugeigenschaften plus eine eigene)

Und genauso verhält es sich doch bei Projekt <> Angebot:

public class Angebot
{
string Angebotsnummer;
dateTime Angebotsdatum;
string Author;
}

public class Projekt : Angebot
{
dateTime Auftragsdatum;
string Projektleiter;
}

jedes Projekt ist ebenso ein Angebot (hat alle Angebotseigenschaften plus diverse eigene).

Irgendwie seh ich den Wald vor lauter Bäumen nicht mehr 😦

Beste Grüße

Hallo Motzi,

für den Design-Teil ist für mich ein Projekt kein Angebot. Aber: ein Projekt hat ein Angebot bzw. kann ein Angebot haben. D.h. übertragen auf OOP eine Komposition, wie

public class Projekt
{
    public Angebot { get; set; }
}

Ein Angebot <- Projekt verstößt auch gegen das Liskovsche Ersetzungsprinzip.
Aber das sind nur meine Gedanken dazu. Vllt. überlegtst du dir das nochmal.

Zurück zum ursprünglichen Problem. Stell dir vor du hast:

class Parent {}
class Child : Parent {}

Jetzt hast du eine Instanz von Base und willst daraus ein Child machen. Geht das? Nein - nicht direkt*. Du musst ein neues Child-Objekt ersetellen und die Eigenschaften (Attribute in der DB) rüberkopieren.

* umgekeht schon, da bei einer Vererbung ein Child immer auch ein Parent ist.

Wenn du aber auf die Komposition, die ich oben die Komposition - od. die hat-eine-Beziehung - erwähnt habe, umsattelst, dann brauchst du im Projekt nur einen Verweis auf das Angebot setzte und das Problem ist gelöst.

Es kann auch umgekehrt sein: Ein Angebot hat ein Projekt - dann ist die Komposisiton umgekehrt zu betrachten. Aber diese Entscheidung von hängt von dir ab, da ich mich in deiner Domäne zu wenig auskenne.

mfG Gü

Hi Motzi

Ich schließe mich Gü an. Ein Projekt sehe ich eben falls nicht als Angebot. Ich sehe die Relation sogar fast als n:m Beziehung. Theoretisch können ja mehrere Angebote zu einem Projekt erstellt werden und aus einem Angebot können ggf. mehrere Teil-Projekte werden (das kommt aber auf die Firmenpolitik an).

Grüße
Flo