App ohne SQL-Server zu installieren: Lokale Datenbank und Entity Framework 6 - SQL Server LocalDB??

verwendetes Datenbanksystem: zu Verfügung stehen mir SQLite 3 und SQLExpress

Hallo,

ich versuche derzeit eine kleine App mit Datenbank zu programmieren. Bisher hatte ich solche Ansätze mit SQLite realisiert, bin aber noch recht neu im Umgang mit Datenbanken und habe erst vor kurzem das Entity Framework für mich entdeckt (um genau zu sein auf udemy.com, dort gibt es einen super Kurs dazu).

Ich möchte mich auf den Code-First-Ansatz konzentrieren - eine kleine Console-App unter Zuhilfenahme von SQLExpress läuft soweit auch einwandfrei.

Ich möchte aber eine App mit lokaler Datenbank schreiben, die den User nicht erst nötigt einen SQL-Server zu installieren und einzurichten. Somit bin ich wieder bei SQLite gelandet, nur um festzustellen, dass SQLite keine Migrations unterstützt. Es gibt dazu zwar einen "Workaround" - der ist aber eben nicht mehr Code-First.

Dann habe ich herausgefunden, dass ich für mein Vorhaben SQL Server Compact verwenden könnte - nur um dann über Wiki zu erfahren, dass Microsoft 2013 bekanntgab, den SQLCE nicht mehr weiter zu entwickeln und statt dessen den SQL Server LocalDB empfiehlt.

Jetzt ist die Verwirrung auf meiner Seite komplett: muss ich da nicht wieder einen SQL-Server auf dem User-System installieren? Und werden dort Migrations unterstützt? Welche Fallstricke erwarten mich bei diesem Ansatz? Welche Alternativen habe ich?

Danke für Erläuterungen!
Gruß
Vorph

Sowohl Sqlite wie auch LocalDB brauchen auch Runtimes. Ganz unabhängig geht nie.
Einmal eben C++ und bei LocalDB einen MSI Installer, mit dem LocalDB installiert wird.
Die meisten haben aber sowieso schon die C++ Redistributables drauf, daher fällt das oft nicht auf.
Aber Ja: LocalDB kann Migrations.

Wirkliche Migrations mit Sqlite gibts erst in EF Core, aber EF Core ist noch weg von einer produktiven Empfehlung.

Ich bin persönlich kein Freund von EF; empfehle durchweg Dapper und FluenMigrations.
FluentMigrations kann aber auch für Sqlite mit EF als Notlösung verwendet werden.

Hallo Abt,

danke für deinen Beitrag. Ich recherchiere gerade verschiedene Quellen - die meisten Lösungen, die ich für SQLite gefunden habe nennen sich zwar "Code-First", setzen aber voraus, dass man eben ein bisschen "mogelt" und zumindest die DataTables im Designer erstellt. Klingt halt ein bisschen halbgar für mich, denn im Umgang mit SQLExpress habe ich ja gerade feststellen dürfen wie elegant und einfach der Code-First-Approach mit Migrations ist.

Dies bringt mich gleich zu einer Interessenfrage:

Ich bin persönlich kein Freund von EF; empfehle durchweg Dapper und FluenMigrations.

Du programmierst ja auf einem ganz anderen Level als Profi - aber gibt es da einfache (für den Laien verständliche) Aspekte, die gegen EF sprechen? Ich meine: mein Vergleich beruht ja nur auf dem Unterschied der regulären sql-queries, mit denen ich noch bis vor kurzem meinen Code verpestet habe und der beauty von Entity Framework, dass sich dankenswerter Weise um dieses dirty work kümmert 😃

Sowohl Sqlite wie auch LocalDB brauchen auch Runtimes. Ganz unabhängig geht nie.
Einmal eben C++ und bei LocalDB einen MSI Installer, mit dem LocalDB installiert wird.
Die meisten haben aber sowieso schon die C++ Redistributables drauf, daher fällt das oft nicht auf.

Ja, das stimmt natürlich. Ich meinte jetzt aber auch eher den Aufwand, den man für SQLServer oder gar bei MySQL betreiben müsste. Für eine App, die beispielsweise deine privaten Kontaktdaten archiviert und verwaltet würde ja niemand so ein Aufwand betreiben (geschweigedenn ein DB-System bemühen).

Ich sehe durchaus die Migrations als Hilfsmittel von EF; aber zeitgleich als komplizierte Angelegenheit, weil alles sehr intransparent abläuft.
Gerade auch der Automatismus beim Erkennen, was sich an den Modellen verändert hat, finde ich beim EF/VS nicht gut und teilweise auch buggy.

Deswegen - insbesondere bei relativ unerfahrenen Entwicklern - finde ich FluentMigrations besser, weil er genau weiß, was passiert und wann und wie die Migration abläuft.

Je nachdem, was Du machen willst, kannst Du Deinen Repository Pattern nicht gegen eine Datenbank laufen lassen, sondern zB. einfach nur gegen ein XML File.
Dann sparst Du Dir alle Abhängigkeiten. So mach ich es bei teilweise sehr einfachen Tools.

Ich sehe durchaus die Migrations als Hilfsmittel von EF; aber zeitgleich als komplizierte Angelegenheit, weil alles sehr intransparent abläuft.
Gerade auch der Automatismus beim Erkennen, was sich an den Modellen verändert hat, finde ich beim EF/VS nicht gut und teilweise auch buggy.

Gut, dass kann ich von meinem Erfahrungsstandpunkt nicht beurteilen. Ich würde aber sowieso jedem empfehlen kleine Veränderungen zu machen und dann eine Migration durchzuführen: im Besten Fall heißt das, eine Spalte hinzufügen, die Eigenschaften festlegen --> Migration. Da muss man schon Disziplin auffahren. Ich habe bisher die Erfahrung gemacht: je besser man eine Vorstellung von seinem Model hat, desto besser klappt's auch mit den Migrations 😉 Und man benötigt bisweilen auch Übung, um in den Up/Down-Methoden der Migrations zu sehen, ob man noch etwas verändern muss, damit man nicht z. B. Daten verliert, wenn man eine Migration rückgängig machen will.

Danke auch für den Hinweis mit den xml-Files: ich hatte dazu vor einiger Zeit im Netz schon was gefunden, insbesondere in Hinblick auf relationale Models. Bin dann doch beim SQLExpress hängen geblieben, weil ich sqllite schon kannte. Hab's aber im Hinterkopf und muss dir was das angeht zustimmen: die App, die ich schreibe, hat später bestimmt <1000 Einträge, da brauchts eine Server-Anwendung nicht. Betrachte das eher als "Übung".

Da kann Ich doch dann gleich die Migration von Hand schreiben, da ist man doch dann schneller.

Wobei Ich mit Sqlite eher Migrator.Net (oder eher noch meinen fork DotNetProjects.Migrator) als Fluent Migrations nutzen würde, da damit auch Dinge gehen die Fluent Migrations in Sqlite nicht unterstützt (Löschen von Spalten, ...)

Da haben wir ja richtig Glück gehabt, dass wir in der qualitativen Softwareentwicklung nicht den Faktor Zeit als einziges im Spektrum haben, sondern durchaus auch die Einfachheit und die hohe Wiederverwendbarkeit zB. mit verschiedenen Datenbank-Engines.