tragl schrieb:

Was ist der genaue Unterschied zwischen .NET und .NET Framework?

kenn mich auch nicht aus - das habich gegoogelt: learn.microsoft.com/de-de/dotn…n-to-choose-net-framework
Net ist sicher cooler als FW: viele neue coole Features drin, und oller Krempel rausgeworfen.
Aber ist so viel neues, dass der Umstieg hart wird. Zb. das Config-System ist ganz neu, da muss man entsprechend alles neu schaffen.

Ich mag EF nicht. Weiss auch nicht, wie einfach es ist, das mit MySql kompatibel zu kriegen.
EF hat statt typDataset typisierte ObjectContainer. Da gibts auch Designer, aber mit EF-CodeFirst wollen sie die abschaffen, oder haben? oder haben wieder eingeführt? Da wird ja ständig umgemodelt.
Jdfs ohne EF-Designer ist der Db-Überblick eines ER-Diagramms verloren - für mich ist das Datenmodellierung mit verbundenen Augen.
Bei uns auf Arbeit der EF-Designer zickt auch immer rum, also nach einer Db-Änderung den ObjectContext aktualisieren ist immer Zitterpartie.
Auch die Arbeit im FormDesigner ist bei EF mühsamer.
Bei typDataset geht das visual, bei EF musste im DesignerCode rumhacken, bevor du bei einem DGV die Spalten gestalten kannst.
Und BindingSource.Sort/Filter funzt net.
EFs Änderungsverfolgung - nutzen wir garnet - ich glaub auch nicht, dass die richtig funktioniert.
Bei EF kann man doll mit LinqToSql iwelche anonymen Datentypen komponieren und abfragen - da generiert EF im Hintergrund die Queries zu.
Leider kann man diesen anonymen Quatsch nicht geändert zurückspeichern, und im Form-Designer kannste auch nicht vernünftig dran binden.
Und Linq2Sql hat nur einen eingeschränkten Befehls-Satz. Welche Befehle möglich sind, erfährst du aber erst zur Laufzeit - also deine Query mag kompilieren, zur Laufzeit aber Ätsch.
Also ich fülle lieber typDataTables, und frage von denen was mit Linq2Object ab, das ist maximal mächtig und zuverlässig.
Und EF fährt auch im Hintergrund noch Sql ab, lazy-loading. Das kann extrem unperformant sein, wenn du 200 Datensätze durchgehst, und je eine Navigations-Property aufrufst.
Das kann man auch unterbinden, indem man am ObjectContext umfangreichen Initialisierungs-Code schreibt - eine Wissenschaft für sich.
Und EF kann keine Datenmengen auf Platte schreiben oder laden - es hängt immer am Datenbank-Tropf.

Jo, insgesamt weiss ich noch nicht, was EF denn nun eigentlich besser macht als typDataset. Also es kann vieles, was typDataset kann, manches eben auch nicht, und kann auch komische dolle Sachen, die ich immer nur üflüssig finde, bzw. mit denen man auch schnell auf Nase fällt.

Ja, vlt. ein grundsätzlicher Unterschied ist, dass ein typDataset ja ein Wrapper um ein untypisiertes Dataset ist. Dadurch kann man generischen Code schreiben für Anwendungsfälle, die bei verschiedenen Tables immer mal wieder vorkommen.
EF-ObjectContexte haben diese Basisklassen nicht - das macht das Erstellen mehrfach verwendbarer Infrastruktur tw. unmöglich.

tragl schrieb:

Was ist der genaue Unterschied zwischen .NET und .NET Framework?

Ich habe mich damit nicht wirklich auseinander gesetzt. Aber ein paar Sachen kann ich dazu sagen.

Wenn du auf NET umsteigst, wirst du feststellen, das einiges nicht mehr direkt drin ist. Da muss man dann Nuget Packete installieren. Ich hatte erstmal in Erfahrung bringen müssen warum kein SerialPort mehr in der Toolbox war, obwohl beim auswählen der Toolbox-Elemente SerialPort gecheckt war, fand aber wie so oft auf SO Hilfe, musste dann das System.IO.Ports Nuget Packet von MS hinzufügen. Aber das hat auch was positives. Ingesammt wird alles schlanker und ich habe den Eindruck das es auch eine etwas bessere Perforomance liefert.

Auch einige neuere Dialoge werden verwendet. Da kann evtl. @-Franky- was zu sagen, der ist dafür der Fachmann hier, ich hab da nicht so einen überblick wie er.

tragl schrieb:

und nutze intensivst das typisierte DataSet.

Als ich auf NET umsteigen wollte sah ich das was im Anhang zu sehen ist, als ich ein prepariertes DGV aufs Form werfen wollte. Ich dachte OMG, muss wieder alles neu lernen. Bin dann direkt auf WPF umgestiegen. Habs zwar nicht bereut, aber hätte ich nicht mal gemusst. Vaporized hat hier geschrieben wie man es machen muss:(Da war ich aber schon bei WPF)
NET 6 wieder Probleme im DataSet?

tragl schrieb:

mir sowieso mal C# aneignen möchte,

C# ist die überlegene Sprache wenn man VB und C# vergleicht. C# hat einige Features die es in VB nicht gibt. Für mich war der Grund des Umstiegs, das ich hauptsächlich mit Sprachen arbeite die C-Syntax haben und ich sogar immer in VB anfing ein ; ans Ende von Codezeilen zu schreiben. Auch bei der Deklaration von Variablen hab ich ständig den Typ zuerst geschrieben(C-Style) statt Dim varName as Type, das nervte irgendwann. Wenn du C# kannst, wird es dir zudem wesentlich leichter fallen, andere Sprachen mit C-Syntax zu lernen.


Aber schon allein weil das Framework nicht mehr weiter entwickelt wird, sollte man zumindest für neue Projekte NET nutzen. Sollten kritische Sicherheitslücken im FW gefunden werden, wird MS die vermutlich noch fixen. Aber die Frage ist, wie lange die das machen werden.