ja, das ist das sicherste.

Hatori schrieb:

Wegen des Verständnisses: Ich war der Meinung, das Dataset bildet eine Zwischenschicht zwischen DB und Formular.

Ja - kann man sagen, wenn auch damit nicht das ganze Konzept beschrieben ist.
Also diese "Zwischenschicht" ist eine kleine Datenbank in vb.Net, gespiegelt von der grossen Datenbank in Sql.
Die kleine Datenbank ist vb.net-Kompatibel, man kann alles mit sauberem .Net-Code erreichen: CRUD, Auswertungen jeder Art, und Databinding - alles mit Code, der durch Intellisense und Background-Compiler unterstützt wird.

Die grosse Datenbank kann auch CRUD und jede Art von Auswertung - Databinding kann sie nicht. Hauptmanko der grossen DB ist, man muss iwelche Strings formulieren und wegschicken, und dann muss man das was zurückkommt mit DataReader und Kram auslesen und in vb.net-Klassen umfüllen, bevor man irgendetwas damit tun kann. Diese Strings, und auch das Rückübersetzen der DB-Antworten - dazu gibts keine Hilfe von Intellisense oder BackgroundCompiler.

Wie dem auch sei - das typDataset, die kleine Datenbank wird aus der grossen DB gespiegelt - sodass die beiden 1:1 zusammenpassen.
Diese Spiegelung findet statt, wenn du das Dataset neu generierst. Sie ist hinfällig, wenn die DB geändert wurde.

Hatori schrieb:

Also schmeiß ich mal alles weg und gehe doch wieder auf ORM, da kann ich die Models ändern, wie ich will.

Ein ORM ist auch nix anneres als eine Spiegelung der DB - welche erstmal generiert werden muss, und die hinfällig ist, wenn die DB geändert wurde.
Allerdings bietet EF-CodeFirst eine neu Möglichkeit: Da kann man den Code ändern, und EF baut daraufhin die Datenbank entsprechend um.
Kenne ich mich nicht mit aus.
AFAIK muss man da beim Coden einiges beachten, damit am anderen Ende die DB auch so entsteht, wie man sich das vorstellt.
Und das Databinding ist auch in bestimmten Szenarien fehlerhaft.
Also wenn du mit EF-CodeFirst gut klarkommst - vielleicht ist das für dich die bessere Wahl.

Mir gefällt am Dataset ja besonders, dass ich meist gar keine Datenbank brauche, sondern die komplette "kleine Datenbank" direkt auf Platte schreiben kann.
So kann ich sogar DatenVerarbeitungs-Anwendungen einfach zippen und zB hier uploaden, und funktioniert.
Mit einer Datenbank da noch im Hintergrund wäre das nicht möglich.

Hatori schrieb:

Ok, danke sehr, wieder was gelernt. Wobei ich Dapper benutze, nicht EF. Letztendlich sollte das aber keine Rolle spielen.

Oh doch - spielt Rolle!
Dapper ist ein besonders schlanker ORM, glaub auch Opensource entstanden, weil EF den Leuten zu monströs wurde, und zuviel komische Sachen macht.
Dapper ist absichtlich "primitiv". Also man muss viel selbst machen, hat dafür aber auch viel Kontrolle.
Es wundert mich allerdings, dass man bei Dapper "einfach das Modell ändern" kann.
Ich hätte von Dapper erwartet: Man kann die DB ändern - dann muss man aber den ORM entsprechend nachbessern.
Aber auch mit Dapper habich eiglich keine praktische Erfahrung.

Ist jedenfalls was sehr anderes als EF, und insbesondere anners als EF-CodeFirst.

(Soweit mein Halbwissen - möge mich bitte korrigieren, wers besser weiss.)

---

Hatori schrieb:

Das Programm, das ich zu bauen versuche, wollen jetzt schon einige befreundete Gruppenleiter haben, ich hab aber auch nicht die geringste Lust, denen erst zu erklären, wie sie MySql runterladen, installieren, die Datenbank anlegen und dann die Tabellen da reinkriegen.

Ein typDataset ohne Datenbank kommt produktiv nur in Frage, wenn nicht mehrere Personen gleichzeitig an den Daten arbeiten können müssen.
Allerdings während der Entwicklung sollte man immer ohne DB arbeiten - du merkst ja selbst, wie umständlich Änderungen am Datenmodell sind, wenn man die DB pflegen muss, und dazu auch die Zwischenschicht - sei die nun ein Dataset, Dapper oder EF.
Eine Datenbank kann man dem Dataset auch nachträglich unterschieben - nämlich dem Dataset ists schnuppe, wie es befüllt wird.
Jdfs. bei DatasetOnly (also ohne DB-Background) ändert man das Modell im Dataset-Designer, und geändert ist.
Man kann sogar die DatenDatei im Editor öffnen, und mit Volltextersatz Benamungs-Änderungen an bestehenden Daten vornehmen.
Aber alles mit gebührender Vorsicht und nicht ohne Backup - weil solche Hacks können auch alles zerschiessen.