Linq2Sql

04/02/2008 - 22:15 von Peter Forstmeier | Report spam
Hallo zusammen,
folgende Tabellen habe ich:

Kunde -> Adresse -> AdressHistory
Mitarbeiter -> Adresse -> AdressHistory
Ansprechpartner ..
Liefernaten
nun habe ich folgendes vor:

Einen DataContext der Adresse und die AdressHistory abbildet und dann
diesen Context in den Kunden u Mitarbeiter Tabellen mit einbinden.
Ist das sinnvoll oder ist es besser jede Beziehung seperat zu modelieren.

Danke schonmal
Peter
 

Lesen sie die antworten

#1 Carl Schaffert
05/02/2008 - 01:09 | Warnen spam
Hallo Peter,


folgende Tabellen habe ich:

Kunde -> Adresse -> AdressHistory
Mitarbeiter -> Adresse -> AdressHistory
Ansprechpartner ..
Liefernaten
nun habe ich folgendes vor:

Einen DataContext der Adresse und die AdressHistory abbildet und dann
diesen Context in den Kunden u Mitarbeiter Tabellen mit einbinden.
Ist das sinnvoll oder ist es besser jede Beziehung seperat zu modelieren.



Aus deiner Schilderung wird man nicht ganz klar... du hast eine
DataContext... den du auch noch in Tabellen(Kunden u Mitarbeiter ) einbinden
kannst... irgendetwas stimmt da nicht. Ein DataContext ist letztendlich
ausschließlich für die Kommunikation zwischen Linq und eines RDBMS
zustàndig, er verbindet deine Entitàten mit der Datenbank. Diese Entitàten
dienen zum einen dazu um die Metadaten zu beschreiben damit die
SQL-Statements von LinqToSql generiert werden können, zum anderen stellen
sie dir Speicher bereit. Prinzipiell hast du zwei Möglichketien um Metadaten
zu beschreiben, die schon erwàhnten Entitàtsklassen (über Attribute) oder
auch ausserhalb in Xml-Dateien mit letzterem hat man sogar etwas mehr
Möglichkeiten um Metadaten zu beschreiben. Im übrigen werden deine Entitàten
im DataContext zwar initialisiert aber nicht instanziiert, letzteres
geschieht an einer ganz anderen Stelle... dazu muss dir das grundlegende
Konzept von LinqToSql(das etwas ganz anderes als LinqToEntities ist) etwas
gelàufiger sein. In erster Linie ist LinqToSQL ein dünne Abstraktionsschicht
um deine SqlStatements über ein Objekt-Modell zu generieren, schon deswegen
solltest du darauf achten, dass dein DB-Design und dein
Entity-Object-Model-Design stimmt. Wenn Ersteres schon gut ist hast du mit
letzterem weniger Aufwand.

Nun, zu deinem Problem musst du noch etwas mehr schildern.. aber
Grundsàtzlich gilt, dass du deine Beziehungen in den Entitàten (per
Attribute) abbilden musst, sofern du sie nicht ausserhalb beschreibst. An
deiner Stelle würde ich mir noch etwas Gedanken hinsichtlich deines
Datenbank-Designs machen... ich hàtte Beispielsweise ein Table Kontakte...
diese Kontakte lassen sich differenzieren/typisieren...
Kunde...Mitarbeiter...Ansprechpartner etc. . jedem der Kontakte lassen sich
eine oder mehrere Adressen zuweisen(oder auch umgekehrt, wei du es eben
brauchst), die sich wiederum differenzieren/typisieren lassen. Was dein
AdressHistory bedeuten soll, ist mir nicht ganz klar, insbesondere ist mir
nicht klar in welcher Beziehung sie zu anderen Daten stehen...

Dann erstellst du deine Entitàten... mal als Beispiel:

ich würde eine Basis-Entitàt "Contact" erstellen, davon würde ich mir
spezialisierte Entitàten ableiten (Customer/Employee etc. ...), in diesen
Entitàten musst du natürlich entsprechende Auflistungen, für zum Beispiel
Adressen etc., bereitstellen... zu denen du natürlich die
Metadaten(insbesondere Beziehungen) angibst... na ja, dann wàre der Anfang
gemacht ;-)

Ich hoffe, dass ich dir ein wenig helfen konnte... bis denne... Carl

Ähnliche fragen