Entity Framework gegenüber LINQ to SQL

Question

Mit der Veröffentlichung von .NET v3.5 SP1 (zusammen mit VS2008 SP1) haben wir nun Zugriff auf das .NET Entity Framework.

Meine Frage ist folgende. Wenn Sie versuchen, zwischen der Verwendung des Entity Framework und LINQ to SQL als ORM zu entscheiden, was ist der Unterschied?

So wie ich es verstehe, ist das Entity Framework (wenn es mit LINQ to Entities verwendet wird) ein "großer Bruder" von LINQ to SQL? Wenn das der Fall ist - welche Vorteile hat es dann? Was kann es leisten, was LINQ to SQL allein nicht leisten kann?

Answer 1

Meine Erfahrungen mit Entity Framework waren weniger als glänzend. Erstens müssen Sie von den EF-Basisklassen erben, also verabschieden Sie sich von den POCOs. Ihr Design muss sich um das EF herum bewegen. Mit LinqtoSQL konnte ich meine bestehenden Geschäftsobjekte verwenden. Außerdem gibt es kein "Lazy Loading", das müssen Sie selbst implementieren. Es gibt einige Workarounds, um POCOs und Lazy Loading zu verwenden, aber die gibt es IMHO nur, weil EF noch nicht so weit ist. Ich plane, nach 4.0 darauf zurückzukommen.

Answer 2

Ich habe eine sehr gute Antwort gefunden aquí die in einfachen Worten erklärt, wann was zu verwenden ist:

Die grundlegende Faustregel für die Wahl des Rahmens ist die Planung von Daten in Ihrer Präsentationsschicht zu bearbeiten.

• Linq-To-Sql - diesen Rahmen verwenden, wenn Sie eine Eins-zu-eins-Bearbeitung planen Beziehung Ihrer Daten in Ihrer Präsentationsschicht zu bearbeiten. Das heißt, Sie nicht vorhaben, Daten aus mehr als einer Tabelle in einer Ansicht oder Seite zu kombinieren oder Seite zu kombinieren.

• Entity Framework - verwenden Sie diesen Rahmen, wenn Sie vorhaben Daten aus mehr als einer Tabelle in Ihrer Ansicht oder Seite zu kombinieren. Um die sind die oben genannten Begriffe spezifisch für Daten, die in Ihrer die in Ihrem View oder auf Ihrer Seite bearbeitet und nicht nur angezeigt werden. Dies ist wichtig zu verstehen.

Mit dem Entity Framework können Sie Tabellendaten "zusammenführen". um sie der Präsentationsschicht in einer bearbeitbaren Form zu präsentieren, und dann Wenn dieses Formular übermittelt wird, weiß EF, wie ALLE Daten aus den verschiedenen Tabellen zu aktualisieren.

Es gibt wahrscheinlich genauere Gründe, EF dem L2S vorzuziehen, aber aber dies ist wahrscheinlich der am einfachsten zu verstehende Grund. L2S hat nicht die Möglichkeit, Daten für die Ansichtsdarstellung zusammenzuführen.

Answer 3

Mein Eindruck ist, dass Ihre Datenbank ziemlich groß oder sehr schlecht konzipiert ist, wenn Linq2Sql nicht Ihren Bedürfnissen entspricht. Ich habe etwa 10 Websites, sowohl größere als auch kleinere, die alle Linq2Sql verwenden. Ich habe mir viele Male Entity Framework angesehen, aber ich kann keinen guten Grund finden, es Linq2Sql vorzuziehen. Das heißt, ich versuche, meine Datenbanken als Modell zu verwenden, so dass ich bereits eine 1:1-Abbildung zwischen Modell und Datenbank habe.

Bei meiner derzeitigen Tätigkeit haben wir eine Datenbank mit über 200 Tabellen. Eine alte Datenbank mit vielen schlechten Lösungen, so dass ich den Vorteil von Entity Framework gegenüber Linq2Sql sehen könnte, aber ich würde es trotzdem vorziehen, die Datenbank neu zu entwerfen, da die Datenbank der Motor der Anwendung ist und wenn die Datenbank schlecht entworfen und langsam ist, dann wird meine Anwendung auch langsam sein. Die Verwendung von Entity Framework auf einer solchen Datenbank scheint ein Quickfix zu sein, um das schlechte Modell zu verschleiern, aber es könnte niemals die schlechte Leistung verschleiern, die man von einer solchen Datenbank erhält.

Answer 4

Einen guten Vergleich können Sie hier finden:

http://www.dotnet-tricks.com/Tutorial/entityframework/1M5W300314-Difference-between-LINQ-to-SQL-and-Entity-Framework.html

http://www.c-sharpcorner.com/blogs/entity-framework-vs-linq-to-sql1

Answer 5

Die Antworten hier haben viele der Unterschiede zwischen Linq2Sql und EF abgedeckt, aber es gibt einen wichtigen Punkt, dem nicht viel Aufmerksamkeit geschenkt wurde: Linq2Sql unterstützt nur SQL Server, während EF Anbieter für die folgenden RDBMS hat:

Zur Verfügung gestellt von Microsoft:

• ADO.NET-Treiber für SQL Server, OBDC und OLE DB

Über Drittanbieter:

• MySQL
• Oracle
• DB2
• VistaDB
• SQLite
• PostgreSQL
• Informix
• U2
• Sybase
• Synergex
• Feuervogel
• Npgsql

um nur einige zu nennen.

Dies macht EF zu einer leistungsstarken Programmierabstraktion über Ihren relationalen Datenspeicher, d. h. Entwickler können unabhängig vom zugrunde liegenden Datenspeicher mit einem einheitlichen Programmiermodell arbeiten. Dies kann sehr nützlich sein, wenn Sie ein Produkt entwickeln, bei dem Sie sicherstellen wollen, dass es mit einer breiten Palette gängiger RDBMS zusammenarbeitet.

Eine andere Situation, in der diese Abstraktion nützlich ist, ist die, in der Sie Teil eines Entwicklungsteams sind, das mit einer Reihe verschiedener Kunden oder verschiedener Geschäftseinheiten innerhalb einer Organisation arbeitet, und Sie die Produktivität der Entwickler verbessern wollen, indem Sie die Anzahl der RDBMS reduzieren, mit denen sie sich vertraut machen müssen, um eine Reihe verschiedener Anwendungen auf verschiedenen RDBMS zu unterstützen.