Diskussion Wann verwendet man welches Datenbankzugriff Framework in .NetCore?­čĄö

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:.
 

Mat

Aktives Mitglied
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.
 

Lowl3v3l

Mitglied
devCommunity-Experte
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
 

Huima

Neues Mitglied
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:
 
Oben Unten