| 

.NET C# Java Javascript Exception

4
Ich stelle hier mal provokant die Frage warum man das 'Entity Framework' verwenden soll?
Es ist bewiesen dass man mit dem 'Datareader' am schnellsten fährt.
Warum soll man das Framework benutzen, das einem, zumal es einen komplizieren unleserlichen Code erzeugt, der zudem auch schwer zu debuggen ist, verwenden soll.
Möglicherweise bin ich einer aus der alten Schule, aber wenn ich DB-Zugriffe mache, will ich immer noch wissen was da passieret, und das weiß man halt damit nicht mehr so genau.
Derzeit arbeite ich auf einer Datenbasis von mehreren Milliarden Datensätzen, und meine Test haben gezeigt, dass alle bisher veröffentlichten Methoden, außerhalb des Readers, schlechter abschneiden.
Ist das ganze ein ‚Hype Mode‘, oder werden wir in 5 Jahren froh sein, dass jemand ohne EF arbeiten kann, und damit Performanz bringt.????
News:
06.04.2013
MStrasser 342 1 8
Wer oder was ist eigentlich dieser 'Ratardaer'?
ffordermaier 08.04.2013
Ich glaube er meint 'DataReader'
multi1209 09.04.2013
Ahh, jetzt wo Du es sagst. Danke. Da wär ich nicht draufgekommen.
ffordermaier 09.04.2013
Danke multi1209, genau das meinter er. Habs auch schon korrigiert ;-))
MStrasser 09.04.2013
Die Antwort ist ganz einfach, man verwendet EF nicht weil es NHibernate gibt. ;-)
cybere 10.04.2013
4 Antworten
2
Provokante Antwort:
Auch wenn Du von der alten Schule bist, solltest Du Dich mit aktuellen Technologien beschäftigen.
Ob das EF bei Milliarden von Datensätzen immer eine gute Lösung ist, mag tatsächlich hinterfragt werden.
Aber es gibt bei Microsoft im Moment wenig Teams, die so produktiv sind wie das EF Team.
Mit dem *EF Profiler* hast Du auch einen guten Überblick über das 'SQL-LINQ-Design' und der Performance.
Auch SPs lassen sich mittlerweile gut anbinden, wobei ich kein Freund von Logik in der DB bin..
07.04.2013
judgy 3,0k 1 1 8
Du hast vollkommen recht, Logik gehört nur bis zu einem gewissen Grad in die DB.
Alte Schule soll aber auch nicht heißen dass ich mit einem Stock herumlaufe ;-))
Neue Technologien sind interessant, das schlimme daran ist, sie kommen immer öfter in immer kürzeren Abständen. Kaum ist ein Projekt fertig, ist es schon wieder veraltet. Ich weiß nicht wie es anderen ergeht, aber ich muss Ergebnisse abliefern. Will man alle neuen Technologien immer gleich verstehen und Testen, so würde, meiner Meinung nach, sehr viel Zeit zu opfern sein.
Den EF-Profiler werde ich mir am WE anschauen. Danke
MStrasser 09.04.2013
Klar, man muss nicht gleich jeder neuen Technologie hinterher laufen. Was das EF angeht, empfinde ich es als beruhigend, dass es dort sehr häufig Neuerungen gibt. Das heisst, das Projekt *EF* lebt. Im Gegensatz zu vielen anderen MS Themen. Z.B. gibt es mit Blick auf WPF kaum Fortschritte in den letzten 4 Jahren.
Insofern muss man immer im Blick haben, was als nächstes stirbt.
Das EF wird es wohl nicht sein ;-)
judgy 10.04.2013
Was heißt hier neue Technik? Nur weil Microsoft da lange nicht fertig gebracht hat, heißt das noch lange nicht, dass ORM ein neues Eisen ist. Wieviele Jahre gibt es denn schon NHibernate? 7, 8, 10 Jahre?
kleffel 18.04.2013
@kleffel: Ich glaube, dass es hier nicht um NHibernate und ORM im Allgemeinen ging, sondern allein um das EF. Ich würde behaupten, dass EF bis vor 3 Jahren nicht wirklich brauchbar war und man daher zuvor NHibernate eingesetzt hat.
Aber dies hat sich in in letzter Zeit geändert. EF hat sich gemausert.
judgy 19.04.2013
4
Ich antworte dir mal genauso provokant:

"Warum nicht ???"

ORM-Frameworks (egal ob Entity Framework oder andere) fügen eine Abstraktionsebene in Richtung Datenbank ein und machen die Datenbankzugriffe transparent (wobei ich nicht weiß, warum man transparent sagt, wenn man das Gegenteil meint ;-)). Der größte Vorteil aus meiner Sicht ist, dass ich eine typisierte Schnittstelle zur Datenbank habe, wodurch bei Änderungen an der Tabellenstruktur weniger Laufzeitfehler auftreten (ich muss halt nur meine Entität ändern und brauche nicht den ganzen Code nach SQL-Staements, welche die Tabelle verwenden, suchen). Außerdem ist nicht jeder Software-Entwickler auch ein SQL-Crack. Ich bin zwar relativ fit in SQL aber mir wäre es einfach lästig neben dem Programmcode auch noch die immer wiederkehrenden Insert, Update und Delete Statements selbst zu schreiben. Ich vertraue einfach darauf, dass die Entwickler des ORM-Frameworks performantes SQL generieren.

Des weiteren bewegt sich der Zeitvorteil zwischen generiertem und handoptimiertem SQL in normalen CRUD-Anwendungen mit einige 10.0000 bis 100.000 Datensätzen in der Regel unterhalb der Wahrnehmungsschwelle.

Ich stimme dir jedoch zu, dass es Sinn macht in großen Datenbanken mit mehreren Milliarden Datensätzen Abfragen von Hand zu optimieren. Dies würde ich aber immer selektiv tun (d.h. wenn es dadurch signifikante Performancevorteile gibt). Solche handoptimierten SQL Statements würde ich dann als Views auf der Datenbank ablegen und diese über ein ORM-Framework mappen.

Gruß
Klaus
07.04.2013
luedi 2,2k 1 9
Durchaus gut argumentiert – Danke.
Es lässt mich erkennen, dass es im speziellen auf das Vorhaben (Project) ankommt, und aus welcher "Ecke" man kommt. Meine Frage kam aus der „Ecke“ mit mehreren hundert Millionen Datensätzen zu hantieren. Hier hab ich bessere Erfahrungen (Messbar) gemacht, lieber eine „Ebene“ tiefer zu Coden und gegebenenfalls die Hauptlast den SPs zu überlassen. Mit Ad-Hoc-Abfragen, wie sie durch das EF erzeugt werden, tut sich der SQL-Server immer etwas schwerer mit der Arbeitsauslastung, Abfrageoptimierer und in der Regel auch schlechtere Ausführungspläne (Recompiles).
MStrasser 09.04.2013
da liegen wir ja auf einer Wellenlänge ;-))
luedi 10.04.2013
4
Auch von mir eine Gegenfrage: warum programmierst Du in .NET und nicht in Assembler oder wenigstens C? Das wäre doch auch "alte Schule" und Du wüßtest genau, welche Maschinenbefehle in welcher Reihenfolge ausgeführt werden und wann wieviele Bytes im Speicher allokiert und wieder freigegeben werden. Und die Performance wäre natürlich auch besser.

Die Antwort ist in beiden Fällen dieselbe: weil Performance nicht alles ist, weil "so schnell wie möglich" nicht besser ist als "schnell genug", weil Abstraktion von technischen Details die Konzentration auf das Anwendungsproblem erleichert und damit die Produktivität erhöht, weil Wiederverwendung von (guten) Detail-Lösungen die Qualität und Effizienz erhöht usw.

Beim EF kommt dann noch ein Punkt dazu: das Ding ist ein OR-Mapper, d.h. es ist dafür gedacht, eine Struktur von .NET-Objekten auf eine Struktur relationaler DB-Tabellen abzubilden. Das ist normalerweise keine triviale Aufgabe, wenn man es selbst machen will, und erfordert in einigen Teilen eine Menge Know-How und in anderen einen Haufen stupide Tipp-Arbeit. Und deshalb: siehe voriger Absatz. Wenn Deine Anwendung aber so aufgebaut ist, dass die Objektstruktur einfach ist und quasi 1:1 der Tabellenstruktur entspricht (und zwar "aus sich selbst heraus", nicht weil aus Bequemlichkeit oder Prinzip die sich die Objekte nach den Tabellen richten müssen), dann entfällt dieser Vorteil. Es bleibt dann der auch nicht gering zu schätzende Aspekt einer Abstraktion von der DB-Technik. Dazu haben andere hier schon einiges geschrieben. Es könnte dann aber auch tatsächlich so sein, dass der Einsatz eines OR-Mappers für deine Anwendung übertrieben und unangemessen wäre. Um zum Eingangsbeispiel zurückzukehren: wenn ich einen Hardware-Treiber programmieren müßte, würde ich wohl nicht zu .NET greifen...
08.04.2013
Matthias Hlawatsch 13,2k 4 9
Ich stimme dir durchaus zu, dass der größte Vorteil in der Abstraktion der DB-Technik liegt.
Braucht man diese aber nicht, geht schon mal ein großer Brocken verloren. Das mit der Wartbarkeit sehe ich eben nicht so eindeutig als Vorteil. Ich hatte da schon mal mehr Zeit vergeudet als damit gewonnen, war aber, zugegebenermaßen ein kleineres Projekt, was wahrscheinlich an der nicht so guten Planung lag, hier sah ich aber in den häufigen Änderungen das Problem und die Umständlichkeit der Anpassungen.
MStrasser 09.04.2013
0
Kommt drauf an, was du mit deinen Daten machst. Wenn du hauptsächlich darauf lesend zugreifst, ist der Vorteil eines O/R Mappers geringer als wenn du intensive CRUD-Anwendungen hast.

Ich habe eine Anwendung (KnowMyUsers) mit ca. 10-15 Tabellen auch mit Plain SQL geschrieben- das war zwar aufwendiger als mit einem ORM, aber akzeptabel. Für Anwendungen mit 100derten von Tabellen fände ich dies jedoch völlig inakzeptabel.

Anderseits können O/R Mapper dir Abstraktionen bieten, die es in SQL nicht gibt.

NHibernate polymorphe Queries:

from ISupportsXYZ


Das erlaubt ganz andere Designs als mit SQL. Hängt natürlich auch wieder vom Einsatz ab, ob es Sinn macht.

Beim Entity-Framework ist aus meiner Sicht die Symbol-Integration ein großer Vorteil.

Entity-Framework erlaubt es eigentlich auch sehr einfach in Performance-kritischen Stellen Hand-optimiertes SQL einzusetzen. Dazu kann man eine Stored Procedure schreiben und die zurückgegebenen Rows werden in einem ComplexType umgewandelt.
18.04.2013
kleffel 654 1 9

Stelle deine .net-Frage jetzt!
TOP TECHNOLOGIES CONSULTING GmbH