Diskussion Wann verwendet man welches Datenbankzugriff Framework in .NetCore?🤔

Huima

Huima

Neues Mitglied
Aktuell arbeite ich an einem neuen privaten Projekt in C# .NetCore.

Jetzt stell ich mir die Frage: "Wie bekomm ich am einfachsten und effektivsten die Daten aus der Datenbank?". Und wann sollte man eine ORM, wie Entity Framework, oder Micro-ORM, wie Dapper, verwenden. Und sollt man noch ADO.Net verwenden?

Der Sinn von meinem Projekt ist eig. neue Technologien zu lernen, deshalb wollte ich mal nachfragen was andere von diesem Thema halten:unsure:.
 
Weil ich mich mit den C#-Frameworks nicht auskenne, eher eine allgemeine Anmerkung:

Wenn die Daten schon vorhanden sind, wirst du sie manuell auf ORMs mappen müssen und ggf die Tabellenstruktur anpassen müssen. Normalerweise lässt du die DB generieren, nicht umgekehrt (aber auch Modelle aus DB basteln geht).

Also wenn die Datenbank schon vorhanden ist, würde ich ein Framework wählen, bei dem die Modelle leicht angepasst werden können und bei dem die Strukturvorgaben nicht so streng sind. Dadurch kannst du dann die DB weitgehend unverändert lassen. Oder du verzichtest auf eine ORM und benutzt Repositories und rohe DB-Abfragen.

Was neue Technologien angeht:
Mach doch mal ein paar Prototypen mit den 5 aktuellsten Frameworks (+ 1x ohne Framework) oder so und dann vergleiche die. Dann lernst du die Vor- und Nachteile kennen. Micro-ORM klingt zum Beispiel nach wenig Overhead aber dafür weniger Features (zB keine Backups). Und ADO ist gar kein ORM, oder? Ansonsten will einem Microsoft ja auch immer Azure andrehen. Könntest schauen, welche Frameworks sie dafür empfehlen.
 
Wenn du das Projekt startest ist erstmal die Frage, ob du überhaupt bei .NetCore bleiben willst, .Net 5.0 kommt demnächst und wird es ersetzen. Fürs Entity-Framework gibts da auch gleich ein paar neue Goodies(z.B. Table-per-Type-Mapping), die man vielleicht gleich mitlernen sollte, ist immerhin die Zukunft.

Ich würde, aber das ist wohl vor allem eine Geschmacksfrage, wenn ich kann immer eher auf ein ORM setzen, statt ADO.Net direkt anzusprechen, aber ADO selbst finde ich eigentlich ziemlich entspannt und gut benutzbar. Fürs ORM defaulte ich eigentlich mittlerweile immer auf das EF, früher hab ich dafür LINQ to SQL benutzt, aber beim Entity Framework fehlt mir eigentlich nichts essentielles, ich hatte da noch nie das Bedürfnis ein anderes ORM auszupacken. Das wichtige ist, dass du halt entsprechend einem ORM zu denken lernst, statt immer "SQL" zu denken. Ist wie beim Sprachen lernen: du sprichst erst gutes Englisch, wenn du Englisch denken kannst, statt immer aktiv umdenken zu müssen. Es lohnt sich definitiv das zu lernen würde ich sagen, schon allein weil es sich, zumindest für mich, in einem strikt objektorientieren Kontext, wie bei C# (oder bei F#, wenn du das objektorientiert betreibst(musst du, um interoperabel mit C# zu sein), insgesamt hab ich über die Sprache sehr viel sehr gutes zu sagen, die sich anzuschauen lohnt sich definitiv auch, wenn du neue Technologien lernen willst!), wirkt das EF auf mich viel natürlicher als ADO direkt benutzen.


Mfg, Lowl3v3l
 
Danke für die guten und ausführlichen Antworten. Ich werde mich jetzt vorerst mit .Net5 und ORMs beschäftigen, weil ich erst wenige Berührungspunkte mit ORMs habe. Im weiteren hab ich keine Probleme mit SQL im Gegenteil oft halte ich SQL für praktisch.

Leider muss ich bei .Net5 noch bis November warten:cry:
 
Zurück
Oben Unten