vb@rchiv
VB Classic
VB.NET
ADO.NET
VBA
C#
Brandneu! sevEingabe v3.0 - Das Eingabecontrol der Superlative!  
 vb@rchiv Quick-Search: Suche startenErweiterte Suche starten   Impressum  | Datenschutz  | vb@rchiv CD Vol.6  | Shop Copyright ©2000-2024
 
zurück

 Sie sind aktuell nicht angemeldet.Funktionen: Einloggen  |  Neu registrieren  |  Suchen

ADO.NET / Datenbanken
Entity-Framework nutzen oder nicht? 
Autor: Schudi
Datum: 07.06.18 20:56

Bislang habe ich DB-Zugriffe (ConnectionString usw.) immer selbst gecodet. Jetzt bin ich auf das Entity-Framework gestossen bzw. gestossen worden. Die Aussage war, dass man heute das EF nutzt statt selber zu coden - zumindest wenn man professionell entwickeln will. Das EF (6) nimmt einem ja, vereinfacht gesagt, jede Menge Arbeit ab und verhindert dabei auch eine Reihe von Programmierfehlern.

Jetzt frage ich mich ob es sinnvoller ist z.B. eine kleine Warenwirtschaft mit dem Entity-Framework zu entwickeln oder ob es doch sinnvoller ist alles von Hand selber zu coden.

Sicherlich wird es hier verschiedene Meinungen geben. Wie macht ihr das? Was meint ihr dazu? Nutzt Ihr vielleicht etwas ganz anderes? Wovon sollte man die Entscheidung abhängig machen? Bion derzeit etwas unentschlossen/verwirrt...
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Entity-Framework nutzen oder nicht? 
Autor: Manfred X
Datum: 07.06.18 21:11

Hallo!

Das EF6 ist eine coole Sache.
Du mußt Dich natürlich einarbeiten.
Allerdings: Wenn Du nur einmal eine einfache Anwendung erstellen willst
und dich mit direkten DB-Zugriffen per Code bereits gut auskennst, ist
die investierte Einarbeitungszeit eventuell nicht lohnend.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Entity-Framework nutzen oder nicht? 
Autor: Schudi
Datum: 08.06.18 06:42

Erst einmal vielen Dank für die Antwort.

Ganz so einfach ist die Anwendung nicht. Es wird eine - wenn auch kleine - Warenwirtschaft. Es gibt also Kunden, Artikel, Kunden- und Artikelgruppen, Lieferanten, diverse Adressen, Aufträge und Statistiken usw. Natürlich gibt es auch viele Querverbindungen (jeder Kunde gehört zum Beispiel einer Kundengruppe an, Aufträge enthalten Artikel, aber auch Verweise auf Kunden bzw. Adressen. Aber ok, was eine WWS ist, muss ich ja eigentlich nicht erklären.

Mir wurde halt gesagt, dass man komplexere Anwendungen nicht mehr per codierten DB-Zugriffen sondern besser per EF6 umsetzen solle. Das hat mich verunsichert. Aber da hat sicherlich jeder eine eigene Meinung.

Ins EF6 arbeite ich mich gerade mit Hilfe eines Tutorials ein, bin aber noch blutiger Anfänger:
http://www.entityframeworktutorial.net/

Kann man dem EF eigentlich auch sagen, dass nicht immer die komplette Tabelle geladen werden soll, sondern nur einzelne Datensätze/Rows? Evtl. per LINQ oder direktem SQL-Befehl?
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Entity-Framework nutzen oder nicht? 
Autor: Manfred X
Datum: 08.06.18 08:59

[I]Mir wurde halt gesagt, dass man komplexere Anwendungen nicht mehr
per codierten DB-Zugriffen sondern besser per EF6 umsetzen solle.
Das hat mich verunsichert. Aber da hat sicherlich jeder eine eigene Meinung.[/I]

Wie bereits erwähnt, kann man keine allgemeine Empfehlung aussprechen.
Das ist eine Frage von (aktuellem) Zeit-Aufwand und (langfristigem) Nutzen.

EF lädt Daten nach Bedarf aus dem DBContext.
Man kann aber auch direkt SQL-Abfragen (EF-Modellspezifisch oder roh) nutzen.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Entity-Framework nutzen oder nicht? 
Autor: Schudi
Datum: 08.06.18 17:44

Nochmals vielen Dank. Ich werde mich dann mal mit dem genannten Tutorial in EF einarbeiten.

Kennst Du evtl. noch ein weiteres gutes Tutorial dazu? Evtl. sogar auf Deutsch?
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.

Einloggen  |  Neu registrieren

Funktionen:  Zum Thema  |  GesamtübersichtSuchen 

nach obenzurück
 
   

Copyright ©2000-2024 vb@rchiv Dieter Otter
Alle Rechte vorbehalten.
Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.

Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel