| |
ADO.NET / DatenbankenEntity-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... | |
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. | |
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? | |
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. | |
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? | |
| 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 |
|
|
sevOutBar 4.0
Vertikale Menüleisten á la Outlook
Erstellen von Outlook ähnlichen Benutzer- interfaces - mit beliebig vielen Gruppen und Symboleinträgen. Moderner OfficeXP-Style mit Farbverläufen, Balloon-Tips, u.v.m. Weitere InfosTipp des Monats Access-Tools Vol.1
Über 400 MByte Inhalt
Mehr als 250 Access-Beispiele, 25 Add-Ins und ActiveX-Komponenten, 16 VB-Projekt inkl. Source, mehr als 320 Tipps & Tricks für Access und VB
Nur 24,95 EURWeitere Infos
|
|
|
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
|
|