Klassen aus vorhandener Datenbank erstellen

Question

Guten Abend,

 

ich habe eine bestehende DB mit so ca. 1000 Tabellen. Für jede Tabelle

benötige ich eine Klasse. Dass ich das nicht mit der Hand schreiben will

dürfte klar sein. Gibt es ein Tool in VS, das so etwas kann oder aus einer

DB eine XSD-Datei erstellt? Oder muss ich mir da selbst etwas schreiben?

 

Danke

 

 

Volker

 

 

Answer 1

Hallo Volker,

evtl. suchst Du nach dem Entity Framework? Das gehört zu der ADO.Net Komponente und bietet einen Data Access Layer.

Auf die Daten kannst Du dann über die generierten Klassen zugreifen und auch LINQ steht Dir voll und ganz zur Verfügung.

http://msdn.microsoft.com/de-de/magazine/cc163399.aspx könnte hier ein Einstieg sein.

Ich hoffe, ich habe Dich richtig verstanden und konnte Dir weiterhelfen.

Mit den besten Grüßen,

Konrad

Answer 2

Hallo Volker,

normal würde ich das mit dem Entity Framework machen, das dann allerdings keine XSD, sondern eine EDMX erstellt - was aber ansich letztlich besser ist:

[Übersicht über das Entity Framework]
http://msdn.microsoft.com/de-de/library/bb399567.aspx

also einfach mit dem EDM Assistenten die DB definieren und dann die Tabellen auswählen.

[Datenpunkte: Übersicht über ADO.NET Entity Framework]
http://msdn.microsoft.com/de-de/magazine/cc163399.aspx

_______________________

Du kannst aber über Menü: Daten / Datenquellen anzeigen / Neue Datenquelle hinzufügen / Datenbank / DataSet / .... Verbindung ... / auch DataSet's (intern XSD persistiert) automatisch aus der DB generieren lassen.

Dahinter stehen auch immer Tools (die u.a Visual Studio benutzt), sodass man das auch programmatisch und nicht unbedingt manuell über Designer diese DataSets (oder auch C# Klassen) erstellen lassen kann. Hilfsweise kann man ggf. auch eigene Text-Erweiterungen einbauen lassen, was dann in Richtung T4 Vorlagen geht.

---

ciao Frank

Answer 3

Hallo Volker,

Gibt es ein Tool in VS, das so etwas kann oder aus einer DB eine XSD-Datei erstellt?

Wenn Du klassisches ADO.NET über typisierte DataSets bzw. TableAdapters einsetzen möchtest:

Assistent zum Konfigurieren von Datenquellen
http://msdn.microsoft.com/de-de/library/w4dd7z6t(v=VS.100).aspx 

Wenn Du hingegen das Entity Framework einsetzen möchtest:

ADO.NET Entity Data Model-Designer:
http://msdn.microsoft.com/de-de/library/cc716685.aspx 

Modellaktualisierungs-Assistent (Entity Data Model-Tools):
http://msdn.microsoft.com/de-de/library/cc716705.aspx 

ADO.NET Entity Data Model-Tools:
http://msdn.microsoft.com/de-de/library/bb399249.aspx 

P.S. Im letzteren Fall (EF) könnte sich - angesichts der Tabellenanzahl - eine Partitionierung des Modells als sehr sinnvoll erweisen:

Matthieu MEZIL - How to split your EDM?
http://msmvps.com/blogs/matthieu/archive/2009/05/27/how-to-split-your-edm.aspx

Gruß
Marcel

Answer 4

Hallo Frank,

 

ich hatte schon mit dem Vorschlag von Konrad angefangen. Mal sehen was rauskommt, wenn die Kiste fertig ist. (Wie lange dauert es erfahrungsgemäß bis EDMX erstellt ist so bei 1000 Tabellen?).

 

Wenn es das nicht ist gehe ich den Weg über Dataset unten.

 

Danke

 

 

Volker

 

 

"Frank Dzaebel" schrieb im Newsbeitrag news:73fc7887-b21e-4455-91ed-5a908982b248...

Hallo Volker,

normal würde ich das mit dem Entity Framework machen, das dann allerdings keine XSD, sondern eine EDMX erstellt - was aber ansich letztlich besser ist:

[Übersicht über das Entity Framework]
http://msdn.microsoft.com/de-de/library/bb399567.aspx

also einfach mit dem EDM Assistenten die DB definieren und dann die Tabellen auswählen.

[Datenpunkte: Übersicht über ADO.NET Entity Framework]
http://msdn.microsoft.com/de-de/magazine/cc163399.aspx

_______________________

Du kannst aber über Menü: Daten / Datenquellen anzeigen / Neue Datenquelle hinzufügen / Datenbank / DataSet / .... Verbindung ... / auch DataSet's (intern XSD persistiert) automatisch aus der DB generieren lassen.

Dahinter stehen auch immer Tools (die u.a Visual Studio benutzt), sodass man das auch programmatisch und nicht unbedingt manuell über Designer diese DataSets (oder auch C# Klassen) erstellen lassen kann. Hilfsweise kann man ggf. auch eigene Text-Erweiterungen einbauen lassen, was dann in Richtung T4 Vorlagen geht.

---

ciao Frank

Answer 5

Hallo Volker,

also 1000 Tabellen beim Entity Framework muß ich Dir allerdings sagen, dass ich hier in bestimmten Anwendungs-Szenarien schon Out of Memory Exceptions gehabt habe (dennoch am Ende mit Techniken hinbekommen), was aber z.T. an vermurksten DB-Strukturen gelegen hat (etwa extrem viele Spalten in einer Tabelle). Es ist unterschiedlich, weil es u.a. sehr stark von der Anzahl der Spalten abhängt. Natürlich auch von den Hardware-Ressourcen des Rechners etc.. Aber vielleicht ~20 Minuten bei ~12 Spalten - die Zeit geht ab 250 Tabellen etwas unlinear hoch. Ich meine, es werden in der EDMX dann vielleicht ca. 4 MB XML Text und ca. 15 MB C# Designer-Datei-Code drin stehen! 

---

ciao Frank

Answer 6

Guten Morgen,

 

ich habe jetzt mal die Version mit EF gestartet, allerdings dürfte das so 2 Wochen laufen, bis ich alle Tabellen endlich eingebunden habe (sind mehr als Tausend und z. T. mit mehr als 25 Spalten, zum Glück aber keine Foreign-Keys). Mit nur ein paar Tabellen sich das ganz gut aus, das Ergebnis ist nur viel umfangreicher als ich das benötige.

 

Ich probier noch mal kurz zu erklären was ich will:

- Jede Tabelle der DB soll als eine Klasse dargestellt werden

- Jede Spalte der DB soll eine Property der Klasse sein

mehr eigentlich nicht.

 

Natürlich kann man das Tippen, aber bei 1000 Tabellen????

 

Volker

 

Answer 7

Hallo Volker,

das macht - wie gesagt - das Entity Framework für Dich.
Wenn - wie ich ja berichtete - 1000 Tabellen mit 12 Spalten 20 Minuten dauern, sollte das mit 25 Spalten aber heute fertig werden, wenn Du es bereits angestartet hast. Auch das Teilen in Sub-Strukturen ist hier zwar logisch möglich/sinnvoll, bringt aber wenig Performance-Gewinn.

    > noch mal kurz zu erklären

gut, das EF macht normal intern etwas mehr, als Du wünscht!
Zum Beispiel INotifyPropertyChanged (und Changing) Handling einbauen.

Was Du da beschreibst sind sogenannte reine POCO-Klassen (ohne Zusatzfunktionalität).
Diese kannst Du zum Beispiel auch über CodeSmith erstellen.
Oder über das downloadbare POCO Template aus den Online Visual Studio Erweiterungen:

[Walkthrough: POCO Template for the Entity Framework - ADO.NET team blog - Site Home - MSDN Blogs]
http://blogs.msdn.com/b/adonet/archive/2010/01/25/walkthrough-poco-template-for-the-entity-framework.aspx

Es wird auch "~etwas" bringen, wenn man es direkt über EdmGen macht, weil dann der Designer nicht angezeigt werden muss. Aber im Groben sollte die Dauer ähnlich sein.

---

ciao Frank

Answer 8

Ich probier noch mal kurz zu erklären was ich will:
- Jede Tabelle der DB soll als eine Klasse dargestellt werden
- Jede Spalte der DB soll eine Property der Klasse sein
mehr eigentlich nicht.

Hallo Volker

Nur falls du ausdrücklich diesen direkten Bezug zu Code suchst, nur zur Vollständigkeit (Zukunft):
das EF4 wird momentan ja Richtung "Code First"  (neue Basis auf 'DbContext') weiterentwickelt (CTP/Beta!),
und es gibt auch da einige/frühe Überlegungen, dass man hier auch von einer zuvor schon/länger
existierenden DB ausgehen könnte, und dann daraus die erste Code-Basis generieren könnte:

EF CTP4 Tips & Tricks: Mapping to an Existing Database
http://romiller.com/2010/07/18/ef-ctp4-tips-tricks-mapping-to-an-existing-database/

 "Code Generation
   If we had a big database with a lot of tables then writing this configuration code is going to become a painful (probably unrealistic) task,
in much the same way mapping a huge model to a database from scratch using the designer or xml wouldn’t be a fun task.
For this very reason the designer will automatically generate a default 1:1 mapping for you as a starting point.
So the logical next step would be to have something analyze your database and give you an object model and mapping code..."

Productivity Improvements for the Entity Framework
http://blogs.msdn.com/b/efdesign/archive/2010/06/21/productivity-improvements-for-the-entity-framework.aspx
 "The productivity improvements will also include a template that generates a derived DbContext..."

PS: die CTP5 erscheint in 'nächsten Tagen/Wochen', RTM wohl 2011/Q1.

Answer 9

Hallo Thomas,

> "Code First"

Volker beschreibt (will) genau das umgekehrte.
Bei "Code First" erstellst Du normal eigene POCO Klassen und leitest daraus die DB ab.
Er hat diese DB hier aber schon und will Klassen davon ableiten. Das ist hier ein "Objekt relationales Mapping" von Datenbank-Objekten in POCO (C# - Klassen) Entitäten.



    http://romiller.com/2010/07/18/ef-ctp4-tips-tricks-mapping-to-an-existing-database/
    -> however Code First also can be used in scenarios where you
         have an existing database.

ja, in diese Richtung ist das auch möglich.
Man beachte aber, er schreibt schon selber: "although the edmx/designer based Database First approach is probably a better fit for the majority of folks".

---

ciao Frank

Answer 10

hallo Volker,

Bei diesen Anfroderungen ist es mit T4 imho auch recht einfach und schnell zu lösen:

http://www.olegsych.com/2007/12/text-template-transformation-toolkit/

---

Microsoft MVP Office Access
https://mvp.support.microsoft.com/profile/Stefan.Hoffmann

Answer 11

Hallo Volker, Marcel,

das P.S. gilt im Falle von 1000 Tabellen auch für typisierte DataSets.

Da faktisch niemand mit 1000 Tabellen gleichzeitig arbeitet  (eine ansatzweise relationale Datenbank vorausgesetzt),
sollte man sich zunächst den Entwurf als solches anschauen und überhaupt klären, womit man was anfangen will.

Gerade mal alle Tabellen zu "bunkern", ist nur was für Hamster -
Und die stopfen ihre Backen dann eher mit EDMGEN voll ;-)

Gruß Elmar

Answer 12

Stefan,

oder ggf. einfach die Info aus meinem ersten Posting: "dann in Richtung T4 Vorlagen", weil es ein "wenig" aktueller ist.

---

ciao Frank

Answer 13

Hallo Elmar,

Ganz Deiner Meinung was das "Bunkern" angeht. Wenn man über tausend Tabellen hat und den EF EDM-Designer ohne Partitionierung des Modells/der Daten verwenden will, wird man nicht nur beim Generieren des Models lange warten müssen, sondern auch beim Anzeigen des Designers, bei der View-Erstellung usw. Schon bei viel kleineren Datenbaken würde man keine Freude mehr am Arbeiten mit dem Designer haben. Bleibt noch der Weg über edmgen.exe - wie bereits von Dir und Frank empfohlen -, das zwar den Designer bei der Modellgenerierung umgeht, dennoch aber die Klassen von EntityObject ableitet, was dem Ziel, einfache Klassen zu generieren widerspricht. Die Generierung von POCO-Klassen mittels ADO.NET POCO Entity Generator setzt aber andererseits ein existierendes Modell voraus (benötigt Verweis auf die edmx-Datei!), so dass man auch damit nicht um die Erstellung des Modells in einem ersten Schritt umher kommt. Es gibt zwar O/R-Mapper (ich verwende oft EntitySpaces), wo das Generieren von Code viel schneller vonstatten geht (oder Codegeneratoren wie MyGeneration, CodeSmith usw.), aber das ändert nichts daran, dass ein DAL mit über tausend Klassen einfach schlechtes Design ist. Ich will mir das im Detail gar nicht vorstellen.

Gruß
Marcel

Answer 14

Hallo Marcel,

da kann ich Dir nur zustimmen.

Ich habe beim Lesen hier auch mit dem Kopf gewackelt ;-))

Gruß Elmar

Answer 15

Tröstet euch, ich habe das jetzt auch nicht gemacht - und ich habe doch das EF genommen...

 

Volker

 

Answer 16

Hallo Volker,

Tröstet euch, ich habe das jetzt auch nicht gemacht - und ich habe doch das EF genommen...

Was hast Du nicht gemacht? Könntest Du das bitte näher erläutern.

Gruß
Marcel

Answer 17

Kein POCO und nicht alles in ein Project. Ich habe das ganze nun gesplittet und auf mehrere Dlls verteilt. Ist doch erheblich übersichtlicher.

 

Volker

Answer 18

Hallo Volker,

Marcel schrieb:  Eine Partitionierung des Modells [könnte sich] als sehr sinnvoll erweisen.
Volker schrieb:   Ich habe das ganze nun gesplittet und auf mehrere Dlls verteilt. 

Das freut mich. Ich halte die Partitionierung des Modells/der Daten für eine akzeptable Vorgehensweise, was die Arbeit mit dem Entity Framework angeht. Wenn die DLLs nicht gleichzeitig von einer einzigen Anwendung referenziiert werden, kann diese Vorgehensweise auch die Anzahl der Klassen im DAL erheblich reduzieren.

Gruß
Marcel

Answer 19

Hallo Volker,

ah schön, dann hast Du es jetzt mit dem Entity Framework hinbekommen, so wie ja zum Beispiel auch in meinem ersten Posting empfahl. Und gleichzeitig übersichtlich gesplittet - ist doch perfekt. Allerdings kann ich Dir aus Erfahrung sagen, es werden später sicher Fehler auftreten, die auf dieser Splittung basieren. Aber gut - Du wirst es in den Griff bekommen.
Dann würde ich mal sagen, ist die Frage hier beantwortet.

---

ciao Frank

Answer 20

Hi zusammen,

 

ich schieb hier mal noch was nach. Ich habe mal aus Interesse eine kleines Programm geschrieben, das die Tabellen und zugehörigen Spalten in POCO-Form (Tabelle=Klasse, Spalte=Property) erstellt. Ergebnis:

 

1089 Tabellen, also 1089 Klassen, ca. 19.500 Spalten/Properties ergibt in o. g. Form sage und schreibe 2,3 GB Quellcode!!!

 

Ich glaube hiermit ist alles gesagt.

 

Volker

Answer 21

Hi Volker,

1089 Tabellen, also 1089 Klassen, ca. 19.500 Spalten/Properties ergibt in o. g. Form sage und schreibe 2,3 GB Quellcode!!!

Ein ernüchternder Nachtrag. Die konkreten Angaben werden sicherlich anderen bei der Orientierung helfen, die wie Du eine große Datenbank in Code 1:1 "nachzubilden" versuchen. Und genau das meinte ich wenn ich sagte: "Das ändert nichts daran, dass ein DAL mit über tausend Klassen einfach schlechtes Design ist."

Gruß
Marcel

Answer 22

Hi Marcel,

dem kann ich nur vehement zustimmen. Ich habe noch nie eine Anwendung gesehen, die so viele Details benötigt. �?blicherweise bildet die Anwendung einen konkreten Arbeitsablauf ab, der nur einen sehr geringen Umfang der externen Datenbank benötigt. Das betrifft sowohl die Breite (Tabellen-/Spaltenzahl) als auch die Tiefe (Datensatzzahl). Für jeden diesen üblicherweise in der Anwendung gekapselten konkreten Arbeitsablauf wird eine auf diesen Arbeitsablauf abgestimmte Inline-Datenbank benötigt. Ob die Inline-Datenbank als DataSet, typisiertes DataSet, EDMX oder auch eigenen Listen/Okjekten angelegt wird, ist bei dieser Betrachtung unerheblich. Wesentlich ist der Abgleich der internen mit der externen Datenbank.

 

--
Viele Grü�?e
Peter

Answer 23

Hallo Peter,

 

der Gedanke alles mal schnell in ein Projekt zu stecken kam folgendermaßen:

 

ERP-System auf SQL-Server soll Daten mit anderen Anwendungen austauschen. Erster Gedanke natürlich ist direkt SQL-Server zu nutzen, aber damit umgeht man die gesamte Business-Logik des ERP.

 

ERP kann aber via COM und MSMQ Daten ein- und ausgehend verarbeiten und Businesslogik anwenden. Das ERP hat eine eigene Programmier-Sprache. Damit das möglichst einfach funktioniert war mein Gedanke komplette Business-Objekte zu übergeben. Diese müssen aber auf beiden Seiten bekannt sein. Da ich nun aber nicht für jeden Vorgang die Objekte zusammenbasteln wollte, wollte ich o. g. Weg gehen und alle Objekte-Definition auf einmal erstellen und bei Bedarf die Funktionen im ERP immer weiter ausbauen ohne die Notwendigkeit die Klassen-Dll neu zu erstellen. Angesichts des Ergebnisses kann dies wohl nicht praktikabel sein, wie ich ja selbst bewiesen habe (1000 Klassen und 2,3 GB).

 

 

Volker

 

 

"Peter Fleischer" schrieb im Newsbeitrag news:acd64f7b-19c1-4fd7-99b5-b45011df3f8a...

Hi Marcel,

dem kann ich nur vehement zustimmen. Ich habe noch nie eine Anwendung gesehen, die so viele Details benötigt. �?blicherweise bildet die Anwendung einen konkreten Arbeitsablauf ab, der nur einen sehr geringen Umfang der externen Datenbank benötigt. Das betrifft sowohl die Breite (Tabellen-/Spaltenzahl) als auch die Tiefe (Datensatzzahl). Für jeden diesen üblicherweise in der Anwendung gekapselten konkreten Arbeitsablauf wird eine auf diesen Arbeitsablauf abgestimmte Inline-Datenbank benötigt. Ob die Inline-Datenbank als DataSet, typisiertes DataSet, EDMX oder auch eigenen Listen/Okjekten angelegt wird, ist bei dieser Betrachtung unerheblich. Wesentlich ist der Abgleich der internen mit der externen Datenbank.

 

--
Viele Grü�?e
Peter

Answer 24

Hallo Volker,

      > 2,3 GB Quellecode ...

in Deinem Szenario sicher,
ruhig noch mal von meinem Anfangsposting wiederholt:
ca. 15MB Quellcode bei 1000 Tabellen mit 12 Spalten - wobei das durch T4 extrem verkleinert werden könnte.
Meinen Ausdruck: "ab 250 Tabellen etwas unlinear hoch" kann man also fast schon als "exponentiell hoch" beschreiben (mit der Anzahl der Spalten).

Gut - Du hattest ja jetzt gesplittet, aber eigentlich kann man eben auch die von mir und Stefan empfohlenen T4 Vorlagen benutzen, wodurch das Code-Ausmaß extrem verringert wird, weil man viele Sachen aus EF Code herauslassen kann und mehr in Richtung reiner POCO -Generierung gehen kann.

Dennoch mal allgemein zum Thema.
Wir haben ja auch große Datenbanken (mit sehr vielen Tabellen und bei bestimmten DBs mit extrem vielen Spalten - deutlich zu viele ;-) - wie machen wir es ...?
nun - wir stellen wichtigen Klassen der Business Logik und nach aussen als Domain Service zur Verfügung. Microsoft empfiehlt auch bei Domain Services !nicht! extrem viele Tabellen damit umzusetzen. Die Tabellen können auch Kunden bei uns flexibel ansprechen. Für ReadOnly-Logik und andere (z.B. keine EF Change Tracking notwendig) nehmen wir dynamische Data Services, die intern latebind arbeiten. Die Funktionalität wird dadurch in eher wenigen generischen Klassen gekapselt. Trotz all dem, theoretisch wären selbst riesige Terrabyte Code-Monster ggf. kein Problem, wenn der Code eben latebind in ordentlichen "Happen" verpackt (auf Anforderung) gehandelt werden kann. Der .NET Jitter unterstützt diese Möglichkeit. Sogar bei Silverlight (über Web) wären somit selbst solche Szenarien performant machbar! Dennoch würde ich jetzt diese Möglichkeit (mit 1100 Klassen) nicht unbedingt in Deinem Fall anstreben.

---

ciao Frank