ASP.NET MVC + LINQ zu SQL oder Entities?

8

Wenn linq to entities veröffentlicht wurde, sagt jeder, dass linq to sql tot ist.

Aber die meisten Bücher und Beispielprojekte von Microsoft-Mitarbeitern verwenden mvc + linq to sql.

Es gibt einen Grund dafür? Die LINQ zu SQL scheint besser für POCO, oder?

    
Felipe Fujiy Pessoto 10.06.2009, 03:04
quelle

6 Antworten

9

Linq to SQL hatte seinen Ursprung in ein Gedankenexperiment . Linq brauchte einen Proof of Concept, und Linq to SQL lieferte das.

Seitdem haben viele in der Benutzergemeinschaft (einschließlich ein paar prominente Microsoft-Mitarbeiter ) Linq zu SQL als das Leichtgewicht übernommen SQL Server ORM der Wahl, vor allem für kleine Projekte wie NerdDinner .

Der Furor begann mit dieser Beitrag vom ADO.NET-Team. Darin heißt es, dass Linq to SQL beibehalten wird und Features hinzugefügt werden, die auf dem Feedback der Benutzergemeinschaft basieren, dass das Entity Framework jedoch der Schwerpunkt zukünftiger Datenzugriffsbestrebungen sein wird.

Viele Nutzer in der Nutzergemeinschaft haben diesen Schritt als " interpretiert, das Microsoft Linq umbringt SQL . "

Microsoft hat nicht geholfen, wenn es hat das Provider-Modell für Linq to SQL deaktiviert, indem einige kritische Klassen versiegelt wurden , sodass Linq zu SQL nur mit SQL Server verwendet werden kann. Das Entity Framework ist das bevorzugte ORM für mehrere Datenanbieter .

Leider scheint das Entity Framework noch nicht zur Prime Time bereit zu sein .

Es hängt also davon ab, an wen Sie glauben. Glauben Sie, dass die Spekulationen (und das sind nur Spekulationen) vieler Blogger, die sagen, dass Linq zu SQL wirklich tot und begraben ist, oder glauben Sie, dass Leute wie Damien Guard von Microsoft sagen, dass Link zu SQL hat ein langes Leben voraus ?

    
Robert Harvey 10.06.2009, 04:00
quelle
3

Linq-to-SQL ist eine großartige Technologie und sehr einfach zu bedienen, so dass es extrem gut auf Demos ausgerichtet ist. Es ist auch eine perfekte Wahl für kleinere, einfachere Projekte, bei denen Sie mehr oder weniger eine direkte 1 haben: 1 Zuordnung von Ihren Tabellen in SQL Server zu Ihren Objekten im Speicher.

Und das sind die restriktivsten Einschränkungen von Linq-to-SQL:

  • Nur SQL Server
  • direkte 1: 1-Zuordnung von Tabellen zu Objekten im Speicher

Wenn das für Sie in Ordnung ist, können Sie Linq-to-SQL verwenden! Auf jeden Fall - MS fügt immer noch Funktionen hinzu und repariert es für .NET 4.0 - es ist noch lange nicht tot.

Entity Framework in seiner v1-Version verfügbar jetzt hat einige Warzen, wie andere Plakate rechtmäßig erwähnt haben (keine POCO-Unterstützung, keine "Domain-Design-First" -Ansatz und viele andere). Aber das Feature-Set von EF v4 sieht sehr überzeugend aus und wird Linq-to-SQL einen Run für sein Geld geben!

Die Hauptvorteile von EF gegenüber Linq-to-SQL in einer Unternehmensumgebung sind die Unabhängigkeit der Datenbank (Sie können sie mit Oracle, Firebird, DB2 und vielen anderen verknüpfen), die entscheidend sein kann, und die Fähigkeit, Sie zu präsentieren mit einem Objektmodell, das von dem physischen Speichermodell in der Datenbank (aufgrund der Abbildung zwischen der konzeptuellen Schicht und der physikalischen Speicherschicht) ziemlich verschieden aussieht.

Es kommt also darauf an, was Sie brauchen: Brauchen Sie einen schnellen Einstieg (Demos, einfachere Apps)? Dann ist Ihre Entscheidung eindeutig Linq-to-SQL (zumindest für den Moment) oder Sie tun es Sie benötigen einen flexiblen Zuordnungsansatz für ein Nicht-SQL Server-Backend - dann wählen Sie Entity Framework.

Marc

    
marc_s 10.06.2009 04:55
quelle
1

Der einzige Grund, warum die Beispiele mit LINQ-to-SQL geschrieben wurden, ist, dass die Einrichtung schnell und einfach ist.

Ansonsten können Sie any ORM verwenden, egal ob EF oder NHibernate oder was auch immer.

    
Jon Limjap 10.06.2009 03:10
quelle
1

Ich persönlich würde mich jetzt an das Entity Framework gewöhnen. Da es mehr Funktionen hat, Provider-unabhängig ist und (vielleicht) aggressiver entwickelt wird. Die zwei häufigsten Beschwerden, die ich höre, sind der Mangel an POCO und das Fehlen von Lazy Loading. Es scheint, dass beide in .NET 4.0 angesprochen werden Ссылка

Abgesehen davon, dass es potentiell schneller (um damit zu beginnen) oder einfacher ist, bin ich mir nicht sicher, ob auf lange Sicht < Vorteil ist. Kennt jemand davon?

    
Loren Paulsen 10.06.2009 04:25
quelle
0

Das von ScottGu geschriebene nerddinner-Beispielkapitel verwendet Linq-To-SQL, unterstützt LINQ-to-SQL nicht, fördert aber auch keine LINQ-To-Entities. Mit ViewModel (Stephen Walther hat einen schönen Beitrag dazu) & amp; Das Repository-Muster, LINQ-To-SQL ist perfekt für die Entwicklung von ASP.NET MVC-Anwendungen

    
indyfromoz 10.06.2009 03:08
quelle
0

Meiner Meinung nach ist Linq to Entity im Moment kein guter Kandidat . Eines der Dinge, die ich an Linq To Entity nicht leiden konnte, ist der Mangel an lässigem Laden, der mich jedes Mal, wenn ich meine Repositories schrieb, an die Wand trieb. Ich denke, das hat es für mich getötet. Die andere Sache ist das ganze Problem mit dem Anhängen und Entfernen von Entitäten, die von mehreren Instanzen des Objektkontextes verwendet werden. Das war ein weiterer Mörder für mich, der zu einer Menge Hacking führte, um Entity-Beziehungen und dergleichen neu zu erschaffen. Ehrlich gesagt, wäre es besser, auf die nächste Version dieses Frameworks zu warten. Ich denke, gute Dinge kommen dafür:)

    
Sergey 10.06.2009 03:36
quelle

Tags und Links