Entity Framework und dynamische Benutzung von MS SQL Server und SQL Server Compact

Hallo zusammen,
ich möchte eine Anwendung erstellen, welche dynamisch zwischen dem MS SQl Server (SQLS) und dem MS SQL Server Compact (CE) entscheiden kann. D.h. es kann zum Beispiel per Konfiguration entschieden werden, welche Datenbank genutzt wird. Da die SQl-Versionen werden ja über verschiedene Objekte gesteuert, implementieren aber einheitliche Interfaces für die DB-Befehle, welche ich an dieser Stelle zur dynamischen Aufrufen verwenden kann.

Da ich nun auch das Entitiy Framwork (EF) nutzen möchte, komme ich beim Mapping allerdings auf Probleme. Da ich ja doppeltes Mapping machen müsste. (Mapping der CE-Version auf die Klassen und der SQLS-Version auf die gleichen Klassen. Geht so ja nicht.)

Vom Vorgehen dachte ich da eigentlich nur an eine Möglichkeit:
Ich würde es dem EF gelich tun. Für jede Datenbank eigene MappingObjekte erstellen und diese dann ein Interface implementieren lasen, welches ich dann für den dynamischen Aufruf nehme. Abhängig von den Einstellungen wird dann die entsprechende Server-Edition aufgerufen.

Allgemeine Fragen:
Habt ihr noch andere Ideen, zur Umsetzung bzw. gibt es andere und bessere Möglichkeiten, außer dem Interface?
Gibt es doch möglichkeiten ein "doppeltes" Mapping mit dem EF zu ermöglichen?
Auf welche Probleme könnte ich stoßen?
Gibt es auf der programmatischen Seite besondere Grenzen bzw. Unterschiede zwischen den SQl-Editionen?

Ich hoffe ich konnte meine Frage ausreichend verständlich formulieren und freue mich über Antworten.

Viele Grüße,
ironhaert

Dir scheinen da einiges an Grundlagen zu EF zu fehlen weshalb Du so umständlich denkst.
Du musst da nichts doppelt mappen.

Initialisiere den Context mit Sql oder SqlCe, den rest macht EF, dafür ist das doch da.

Funktioniert, soweit ich über SQL CE Bescheid weiß, auch nur, wenn du es schaffst die Datenbank als reine Daten-Halle zu verwenden. Sobald du irgendwo Logik in die DB auslagerst (Prozeduren, Views) etc. geht das nicht mehr.

CE zu verwenden funktioniert meines Erachtens nur sehr bedingt für eher kleine Projekte.

@FZelle

Initialisiere den Context mit Sql oder SqlCe, den rest macht EF, dafür ist das doch da.

Das genau ist mein Geadanke, also kein ODER, sonder UND (dynamische Entscheidung via Config-File), welche Datenbank verwendet wird. D.h. es sollen beide Datenbanken-Möglichkeiten unterstützt werden. Anbhängig von der vorherrschenden Situation (SQL-Server-Lizenzen vorhanen oder nicht).

@tkrasinger
Die Einschränkungen der CE-Version sind mir (zumindest theoretisch durchs Einlesen) bekannt. Also Stored Procedures, Views, etc. wird es vorerst nicht geben und die physikalischen Grenzen müssten zunächst ausreichen. Falls die Logik später zunimmt, bestünde die Möglichkeit der Erweiterung nur für die SQL-Server-Variante vorzunehmen.

Funktioniert...

Immerhin bist du auch der Meinung, es geht so, wie ich mir es gedacht habe; Das freut mich schon mal. 😃

CE zu verwenden funktioniert meines Erachtens nur sehr bedingt für eher kleine Projekte.

Ich bin mal gespannt ob es für mein Vorhaben ausreicht. Generell wird es schon ein großes Schema und könnte auch viele Schreibzugriffe geben aber die Datenmenge sollte im Überschaubaren Rahmen bleiben. Und wer mehr will, kann dann zur Server-Version greifen.

Danke für eure Antworten,
Gruß ironhaert

@ironhaert:
Das hast du wohl absichtlich falsch verstanden.
Natürlich war gemeint das zur Laufzeit zu machen, indem du dem Context mit entweder MSSql oder SqlCe zu erstellen.

@tkrasinger:
Selbst große Datenbanken kann man komplett ohne SP's und Co erstellen und benutzen.
Das verteilen von Businesslogik macht auch nicht immer Sinn, und SP's sind auch nicht per se schneller als das was man per ORMapper herauskommt, wenn man weiß was man tut.

Aber diese Diskussion wird hier ständig geführt.

@FZelle

Das hast du wohl absichtlich falsch verstanden.

Also falsch verstanden habe ich das wohl aber eigentlich nicht absichtlich.

Dir scheinen da einiges an Grundlagen zu EF zu fehlen weshalb Du so umständlich denkst. Du musst da nichts doppelt mappen.

Mit den fehlenden Grundlagen liegts du richtig, da ich noch mehr am Einarbeiten in EF bin. Mit doppeltem Mapping war halt gemeint, ob es möglich ist, die gleichen Entityklassen bzw. eine einzige Entityklassen zu verwenden und dynamisch auf die gewählte Datenquelle gemappt wird (SQL CE oder Server).
Weil bei meiner Vorgehensweise, würde ich ja für jede DB ein "eigenes" Mapping machen und diese dann Kontextbezogen über das Interface aufrufen. Das Bedeutet, ich müsste dem generierten Code eigentlich nur die Interface-Implementierung hinzufügen.

Ich habe mich nun nochmals ein wenig mit dem EF beschäftigt. Hänge allerdings an dem Punkt, dass ich die DB-Verbindung dynamisch wechseln kann:
Beim automatischen mappen durch den Designer wird ja automatisch ein Connection-Eintrag in der App-Config angelegt und im generierten Code (xxx.Designer.cs) im ObjectContext verwendet. Hier müsste ich nun den CE-Verbindungsstring zur Server-Verbindungsstring verwenden aber so direkt funktioniert das leider nicht. Ich werde mich demnächst nochmal genauer damit und dem EF auseinandern setzen.

Also nochmal zur eigentlichen Fragestellung:

Wenn ich das richtig verstanden habe möchtest du einfach nur eine Anwendung haben die mit dem EF arbeitet jedoch unabhängig davon sein soll, welche Datanbank dahinter hängt?

Dafür habe ich erst vor ca. einen Monat selbst eine Lösung gesucht.
Du musst für jede Datenbank (die alle absolut Identisch sein müssen(!) ) ein eigenes Entity Data Model erzeugen. von welchem Model du deine Entitäten generierst ist egal!

In deiner Anwendung brauchst du dann nur noch deinen connectionString auf die Datenbank anpassen, die du verwenden willst 😃

Da muss wie ich oben schon gesagt hatte nichts doppelt gemacht werden.
http://msdn.microsoft.com/en-us/library/cc716756.aspx

Du musst nur den entsprechenden Connectionstring beim anlegen des Context übergeben.
Natürlich ist penible darauf zu achten das das Schema passt, aber ansonsten muss da zwischen MSSql und SqlCompact nichts gemacht werden.

@pilipu
Danke für deine Antwort. Genau das was du beschreibst, war mein Gedanke. Aber ich dachte evtl. gibt es ne Möglichkeit, mit nur einem Entitiy Data Model(EDM) das ganze zu bewerkstelligen, z.B. indem ich den generierte Code des EDM erweitere o.ä.

Weil mehrere Modelle kann nervig werden, weil: Wenn sich das Datenmodell ändert, dann muss auch noch das jeweilige EDM geändert werden und so hätte man evtl. ein einziges Allgemeines. (Wobei das EDM ändern ja nur en paar Klicks sind^^).
Weitere Vorteil wäre: Man bräuchte nicht, wie ich beschrieben habe über Interfaces übe das entsprechende Modell zugreifen, sondern direkt auf das einzige Modell.

@FZelle
Also, wenn du sagst es geht auch über das Tauschen des Connection-Strings, dann werd ich das demnächst nochmal versuchen. Hab wohl bei Test den Conn-String, falsch angegeben.
Danke für deine Hilfe.

Naja, mal schauen, wie's weitergeht. Ob wir das EF verwenden ist eh noch nicht sicher. Aber es war mal interessant anzuschauen.

Viele Grüße,
ironhaert

Da hast du wahrscheinlich recht.
Deshalb bin ich ja auch dran, mich mit den Thematiken auseinander zu setzen. 😉
Und ob Verwendung EF oder nicht, war eigentlich eher so gemeint, dass evlt. andere Dinge in Prio geräten könnten.