Entity Framework vs LINQ to SQL

828

Teraz, gdy .NET v3.5 SP1 został wydany (wraz z VS2008 SP1), mamy teraz dostęp do frameworku encji .NET.

Moje pytanie brzmi: Kiedy próbujesz zdecydować się na użycie Entity Framework i LINQ do SQL jako ORM, jaka jest różnica?

W moim rozumieniu Entity Framework (w połączeniu z LINQ to Entities) jest „starszym bratem” LINQ na SQL? Jeśli tak jest - jakie to ma zalety? Co może zrobić, że LINQ to SQL nie może zrobić samodzielnie?

Chris Roberts
źródło
138
Myślę, że poniższe odpowiedzi powinny zostać ponownie przeanalizowane, ponieważ od dawna EF został wydany, więc nowi programiści, którzy się tu znajdą, mogą odnieść złe wrażenie. EF stał się WIELKIM i ŁATWYM narzędziem od czasu jego wczesnego wydania. Właśnie skonfigurowałeś połączenie z bazą danych i jest to 90% wszystkiego, czego potrzebujesz. Bardzo szybki rozwój z doświadczonego punktu widzenia! Stamtąd - LINQ jest twoim najlepszym przyjacielem. Jest wysoce konfigurowalny, MVC po prostu go uwielbia, a ludziom, którzy mówią, że jest zły - Naucz się go najpierw używać (i zdobądź również LINQ)!
graumanoz
10
Właśnie dlatego jest jasne - to nie tak, że masz teraz wybór - MSFT skutecznie zabiło LINQ2SQL na rzecz EF. Jednak fakt, że MSFT open source EF pomógł mu ssać mniej i zdecydowanie poprawia się. Ale dla każdego, kto wejdzie w EF - pamiętaj, aby zrozumieć, że wciąż jest wiele dziwactw w EF. Napisałem o jednym - stackoverflow.com/questions/305092/…
nikib3ro
4
@ kape123, (a) LINQ do SQL nie jest „martwy”; nadal jest użyteczny; (b) LINQ to SQL jest standardową metodą dostępu do danych w rozwoju Windows Phone 8.
Ryan Lundy
9
@ user3308043, [potrzebne źródło].
Ryan Lundy,
3
@ Kyralessa - od 2010 r. (Wraz z wydaniem .NET4.0, najnowszego cytatu, jaki mogłem znaleźć), MS potwierdziło, że chociaż niektóre inwestycje mogą być dokonane w LINQ2SQL, „większość naszych całkowitych inwestycji będzie w jednostce Struktura."
kmote

Odpowiedzi:

483

LINQ na SQL obsługuje tylko mapowanie 1: 1 tabel bazy danych, widoków, sproców i funkcji dostępnych w Microsoft SQL Server. To świetny interfejs API do szybkiego budowania dostępu do danych w stosunkowo dobrze zaprojektowanych bazach danych SQL Server. LINQ2SQL został wydany po raz pierwszy z C # 3.0 i .Net Framework 3.5.

LINQ to Entities (ADO.Net Entity Framework) to API ORM (Object Relational Mapper), które pozwala na szeroką definicję modeli domen obiektowych i ich relacji z wieloma różnymi dostawcami danych ADO.Net. Jako taki, możesz mieszać i dopasowywać wielu różnych dostawców baz danych, serwerów aplikacji lub protokołów, aby zaprojektować zagregowane połączenie obiektów, które są zbudowane z różnych tabel, źródeł, usług itp. ADO.Net Framework został wydany z .Net Framework 3.5 SP1.

To jest dobry artykuł wprowadzający na temat MSDN: Wprowadzenie LINQ do danych relacyjnych

Kris
źródło
wygląda na to, że używasz LINQ do SQL w celu zapytania w EF
PositiveGuy
11
@ CoffeeAddict, chociaż są bardzo podobne w stylu za pomocą lambda LINQ, każdy interfejs API ma zupełnie inne podstawy. Na przykład sposób, w jaki LINQ2SQL generuje zapytania SQL, pozwala na korzystanie z funkcji SQL, podczas gdy L2E nie, lub przynajmniej nie, począwszy od 2008 r.
Kris
2
Podejście obiektowe EF sprawia, że ​​jest naprawdę łatwe i wygodne w użyciu, można je kodować bardzo szybko, zarządzać. Dla mnie to najlepszy sposób na dostęp do danych.
Antoine Pelletier
10
Ta odpowiedź jest nieaktualna. Teraz Linq na SQL obsługuje mapowanie
one2many
201

Myślę, że szybka i brudna odpowiedź brzmi:

  • LINQ to SQL to szybki i łatwy sposób to zrobić. Oznacza to, że przyspieszysz i dostarczysz szybciej, jeśli pracujesz nad czymś mniejszym.
  • Entity Framework to wszechstronny, bezproblemowy sposób na zrobienie tego. Oznacza to, że zajmiesz więcej czasu z przodu, będziesz rozwijać się wolniej i będziesz mieć większą elastyczność, jeśli pracujesz nad czymś większym.
Brad Tutterow
źródło
32
Będziesz także miał tendencję do pisania mniejszej liczby wierszy kodu w L2S, aby osiągnąć to samo, co w przypadku EF. Brak leniwego ładowania w EF oznacza, że ​​zawsze sprawdzasz, czy coś zostało załadowane, czy nie.
Paul Mendoza
Brad, co byś polecił na stronie e-commerce? Chodzi mi o to, że nie widzę nic poza zwykłymi CRUD-ami ...
PositiveGuy
2
@ CoffeeAddict, oczywiście, pierwsza trójka najczęściej głosowanych odpowiedzi mówi L2S dla zwykłego CRUD
IsmailS
11
@Banford Z EF w .NET 4.0 Myślę, że jest lepszy niż L2S. Funkcje, których brakowało w EF w wersji 3.5, które L2S zostały dodane do EF w .NET 4.0. Twoje instrukcje LINQ teraz w EF w .NET 4.0 będą wyglądały prawie tak samo jak te w L2S. EF daje ci kilka dodatkowych rzeczy, które możesz teraz zrobić oprócz tego, co oferuje L2S.
Paul Mendoza
40
Ta odpowiedź ma teraz 5 lat i jest dość nieaktualna. Entity Framework 6 jest teraz w wersji Beta i jest znacznie ulepszony, obejmuje leniwe ładowanie, obsługę enum itp. Itp.
Tim
109

Czy LINQ to SQL jest naprawdę martwy? autor: Jonathan Allen dla InfoQ.com

Matt Warren opisuje [LINQ to SQL] jako coś, co „nigdy nie powinno istnieć”. Zasadniczo miał to być stand-in, aby pomóc im rozwinąć LINQ, dopóki prawdziwa ORM nie będzie gotowa.

...

Skala Entity Framework spowodowała, że ​​nie dotrzymała terminu .NET 3.5 / Visual Studio 2008. Został ukończony na czas niestety o nazwie „.NET 3.5 Service Pack 1”, który bardziej przypominał wydanie główne niż dodatek service pack.

...

Programiści nie lubią [ADO.NET Entity Framework] ze względu na złożoność.

...

Począwszy od .NET 4.0, LINQ to Entities będzie zalecanym rozwiązaniem dostępu do danych dla LINQ do scenariuszy relacyjnych.

Zack Peterson
źródło
56
W rzeczywistości nie lubimy EF, ponieważ ma tak kiepskiego projektanta i jest tak bardzo, bardzo wadliwy. Nigdy nie widziałem, żeby było tak skomplikowane.
BlueRaja - Danny Pflughoeft
12
Wiele dużych witryn e-commerce używa LINQ do SQL. Przykłady: Redbox, Stackoverflow itp.
PositiveGuy
14
Znam wielu dobrych programistów, którzy używają LINQ do SQL i twierdzą, że te artykuły są całkowicie przesadzone. Zgadzam się. LINQ to SQL był używany w potężnych domenach .com i nadal nim jest.
PositiveGuy,
4
Tak, wywołanie funkcji .ToString () dla właściwości liczby całkowitej w zapytaniu L2EF nie powinno powodować wyjątku.
StingyJack,
3
@ BlueRaja-DannyPflughoeft Czy to nadal prawda po ponad 5 latach?
Vikas Rana,
94

Istnieje wiele oczywistych różnic opisanych w tym artykule @lars, ale krótka odpowiedź to:

  • L2S jest ściśle powiązany - właściwość obiektu do określonego pola bazy danych lub bardziej poprawnie mapowanie obiektu do określonego schematu bazy danych
  • L2S będzie działać tylko z SQL Server (o ile mi wiadomo)
  • EF umożliwia mapowanie jednej klasy do wielu tabel
  • EF będzie obsługiwał relacje MM
  • EF będzie mógł kierować reklamy do dowolnego dostawcy danych ADO.NET

Pierwotnym założeniem było, że L2S służy do szybkiego rozwoju, a EF do bardziej „przedsiębiorczych” aplikacji n-tier, ale to trochę sprzedaje L2S.

JamesSugrue
źródło
13
Twój cytat „L2S będzie działał tylko z SQL Server (o ile mi wiadomo)” wymaga aktualizacji: projekt open source „dblinq” zastępuje zestaw LINQ to SQL tym, który może komunikować się z MySQL, PostgreSQL, Ingres, Firebird, SQLite. .. i Microsoft SQL (oczywiście).
Contango,
1
czekaj ... więc EF nie tworzy ściśle powiązanych obiektów DL?
PositiveGuy,
7
tak, pierwotne założenie, że L2S nie jest rozwiązaniem dla przedsiębiorstw, nie jest już prawdą. Mam na myśli StackOverflow działa na L2S i kilka innych domen .com. Takich jak Redbox i wiele innych.
PositiveGuy,
74

LINQ do SQL

  1. Jednorodne źródło danych: SQL Server
  2. Zalecany do małych projektów tylko wtedy, gdy struktura danych jest dobrze zaprojektowana
  3. Mapowanie można zmienić bez ponownego wypełniania za pomocą SqlMetal.exe
  4. .dbml (język znaczników bazy danych)
  5. Mapowanie jeden do jednego między tabelami i klasami
  6. Obsługuje dziedziczenie TPH
  7. Nie obsługuje złożonych typów
  8. Podejście do przechowywania
  9. Centralny widok bazy danych
  10. Utworzony przez zespół C #
  11. Obsługiwane, ale nie planowane dalsze ulepszenia

Entity Framework

  1. Źródło danych Heterogeneus: obsługa wielu dostawców danych
  2. Zalecany do wszystkich nowych projektów z wyjątkiem:
    • małe (LINQ do SQL)
    • gdy źródłem danych jest plik płaski (ADO.NET)
  3. Mapowanie można zmienić bez ponownego wypełniania podczas ustawiania modelu i mapowania plików Artefakt procesu metadanych do kopiowania do katalogu wyjściowego
  4. .edmx (Entity Data Model), który zawiera:
    • SSDL (język definicji schematu pamięci)
    • CSDL (Conceptual Schema Definition Language)
    • MSL (język specyfikacji mapowania)
  5. Odwzorowania jeden do jednego, jeden do wielu, wiele do jednego między tabelami i klasami
  6. Obsługuje dziedziczenie:
    • TPH (tabela według hierarchii)
    • TPT (tabela według typu)
    • TPC (tabela według klasy betonu)
  7. Obsługuje złożone typy
  8. Podejścia oparte na kodzie, najpierw na modelu, najpierw na pamięci masowej
  9. Zorientowany na aplikacje widok bazy danych
  10. Utworzony przez zespół SQL Server
  11. Przyszłość interfejsów API danych Microsoft

Zobacz też:

Ryszard Dżegan
źródło
6
To najbardziej aktualna i szczegółowa odpowiedź.
ErTR
2
Czy Entity Framework nie używa LINQ do SQL, gdy, powiedzmy, piszesz dbSet<Orders>.Where()...ToList()? Myślę, że wprowadzanie w błąd Entity Framework jest sprzeczne z LINQ i SQL.
Don Cheadle
4
@mmcrae EF nie używa L2S, oba są dostawcami linq do bazowych baz danych. Jeśli interpretujesz go jako Linq-to-a-database, podobny do linq-to-objects i linq-to-xml, to tak, oba są podobne w linq-to-a-database. Ale nie, EF nie używa L2S (lub odwrotnie). Dwa całkowicie oddzielne narzędzia.
Maarten
4
„Zalecane do wszystkich nowych projektów z wyjątkiem ... małych” Nie zgadzam się. Code First to niezwykle szybki sposób na rozpoczęcie działalności przy małych projektach. Poza tym świetna aktualizacja tego pytania.
DrewJordan,
51

Moje doświadczenie z Entity Framework było mniej niż gwiezdne. Najpierw musisz dziedziczyć po klasach podstawowych EF, więc pożegnaj się z POCO. Twój projekt będzie musiał być oparty na EF. Dzięki LinqtoSQL mogłem używać moich istniejących obiektów biznesowych. Ponadto nie ma leniwego ładowania, musisz to zaimplementować samodzielnie. Istnieje kilka sposobów wykorzystania POCO i leniwego ładowania, ale istnieją IMHO, ponieważ EF nie jest jeszcze gotowy. Planuję wrócić do tego po 4.0

Jiyosub
źródło
7
Brak obsługi POCO jest najważniejszym powodem, dla którego wybrałem LINQ na SQL zamiast Entity Framework. Mogę ponownie odwiedzić EF, jeśli włączą go do następnej wersji, jak obiecują. Istnieje kilka dodatkowych projektów, które wykonują POCO dla EF, ale nie są wystarczająco czyste.
Joseph Ferris
27
W przypadku, gdy ktoś (jak ja) nie wie, co oznacza POCO: Plain Old CLR Object
CBono
4
Naprawdę nie rozumiem, o co tyle zamieszania w nieobsługiwaniu POCO ... to jeszcze jeden poziom abstrakcji. Utwórz fabrykę, wstrzykując repozytorium danych i konstruuj tam swoje POCO. To i tak chyba dobry pomysł.
EightyOne Unite
3
Słyszę, że POCO jest możliwe w EF 4
PositiveGuy
8
Wsparcie POCO jest obecnie dostępne, a dziedziczenie nie jest już wymogiem dla klas encji @CoffeeAddict POCO jest po prostu prostym obiektem bez zależności od konkretnego frameworka i stanowi główną część nowoczesnych wzorców frameworku
Chris McGrath
46

Znalazłem tutaj bardzo dobrą odpowiedź , która wyjaśnia, kiedy użyć tego, co w prostych słowach:

Podstawową zasadą, której należy użyć, jest planowanie edycji danych w warstwie prezentacji.

  • Linq-To-Sql - użyj tego frameworka, jeśli planujesz edytować relację jeden-do-jednego twoich danych w warstwie prezentacji. Oznacza to, że nie planujesz łączyć danych z więcej niż jednej tabeli w jednym widoku lub stronie.

  • Entity Framework - użyj tego frameworka, jeśli planujesz łączyć dane z więcej niż jednej tabeli w widoku lub na stronie. Aby to wyjaśnić, powyższe warunki dotyczą danych, które będą przetwarzane w widoku lub na stronie, a nie tylko wyświetlane. To ważne, aby zrozumieć.

Dzięki Entity Framework możesz „scalić” dane z tabeli, aby przedstawić je warstwie prezentacji w edytowalnej formie, a następnie po przesłaniu tego formularza EF będzie wiedział, jak zaktualizować WSZYSTKIE dane z różnych tabel.

Prawdopodobnie istnieją bardziej dokładne powody, aby wybrać EF zamiast L2S, ale prawdopodobnie byłby to najłatwiejszy do zrozumienia. L2S nie ma możliwości scalania danych w celu prezentacji widoku.

Nawaz
źródło
36

Mam wrażenie, że twoja baza danych jest dość bogata lub bardzo źle zaprojektowana, jeśli Linq2Sql nie spełnia twoich potrzeb. Mam około 10 stron internetowych, zarówno większych, jak i mniejszych, wszystkie korzystających z Linq2Sql. Szukałem frameworka Entity wiele razy, ale nie mogę znaleźć dobrego powodu, aby używać go w Linq2Sql. To powiedziawszy, staram się używać moich baz danych jako modelu, więc mam już mapowanie 1: 1 między modelem a bazą danych.

W mojej obecnej pracy mamy bazę danych z ponad 200 tabelami. Stara baza danych z wieloma złymi rozwiązaniami, dzięki czemu mogłam zobaczyć przewagę Entity Framework nad Linq2Sql, ale nadal wolałbym przeprojektować bazę danych, ponieważ baza danych jest silnikiem aplikacji i jeśli baza danych jest źle zaprojektowana i powolna, to moja aplikacja będzie również powolny. Używanie frameworku Entity w takiej bazie danych wydaje się być poprawką służącą do ukrycia złego modelu, ale nigdy nie może ukryć złej wydajności uzyskanej z takiej bazy danych.

terjetyl
źródło
1
Brakuje Ci sensu - nawet w przypadku małych baz danych możesz chcieć czegoś innego niż relacja 1: 1 między tabelami baz danych a obiektami kodu / domeny. Tylko zależy od tego, ile abstrakcji chcesz w obiektach magistrali / domeny.
alchemiczny
18
Zrozumiałem to :) Dzisiaj lubię ręcznie kodować moje podmioty gospodarcze. Nadal używam Linq2sql, ale tylko w moich repozytoriach, w których uzyskuję dane za pomocą Linq2sql i przekształcam jednostki linq2sql w moje niestandardowe jednostki biznesowe. Może trochę więcej pracy niż przy użyciu mapera or-mapera, ale nadal chcę, aby moja warstwa biznesowa była wolna od jakiegokolwiek kodu specyficznego dla mapera OR.
terjetyl
25

Dobre porównanie można znaleźć tutaj:

wprowadź opis zdjęcia tutaj

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

Omer K.
źródło
2
Niektóre rzeczy w odpowiedzi są nieprawidłowe. EDMX nie jest wymagany, jeśli używasz Code First. I nie rozumiem, jak DI wchodzi w grę, kiedy używasz Code First.
Maarten
1
Również Linq do SQL może dobrze wypełnić DB z klas modeli. Nie jestem pewien, czy może również wygenerować samą bazę danych, ale generowanie schematu i tabel jest zgodne z możliwościami SQL dla Linq.
Tom Lint
Dzięki za odpowiedź, myślę, że można użyć sqlmetal.exe docs.microsoft.com/en-us/dotnet/framework/tools/… do generowania kodu / mapowania z bazy danych podczas używaniaLinq to SQL
Vinod Srivastav
23

Odpowiedzi tutaj obejmowały wiele różnic między Linq2Sql a EF, ale jest kluczowy punkt, na który nie poświęcono wiele uwagi: Linq2Sql obsługuje tylko SQL Server, podczas gdy EF ma dostawców dla następujących RDBMS:

Dostarczone przez Microsoft:

  • Sterowniki ADO.NET dla SQL Server, OBDC i OLE DB

Za pośrednictwem zewnętrznych dostawców:

  • MySQL
  • Wyrocznia
  • DB2
  • VistaDB
  • SQLite
  • PostgreSQL
  • Informix
  • U2
  • Sybase
  • Synergex
  • ognisty Ptak
  • Npgsql

aby wymienić tylko kilka.

To sprawia, że ​​EF jest potężną abstrakcją programowania nad relacyjnym magazynem danych, co oznacza, że ​​programiści mają spójny model programowania do pracy niezależnie od bazowego magazynu danych. Może to być bardzo przydatne w sytuacjach, w których opracowujesz produkt, który chcesz zapewnić, że będzie współpracował z szeroką gamą popularnych RDBMS.

Inną sytuacją, w której ta abstrakcja jest użyteczna, jest sytuacja, w której należysz do zespołu programistów, który współpracuje z wieloma różnymi klientami lub różnymi jednostkami biznesowymi w organizacji, i chcesz poprawić produktywność programistów poprzez zmniejszenie liczby RDBMS, którymi muszą oni stać się obeznany w celu obsługi szeregu różnych aplikacji oprócz różnych RDBMS.

żagiel
źródło
15

Odkryłem, że nie mogę korzystać z wielu baz danych w tym samym modelu bazy danych podczas korzystania z EF. Ale w linq2sql mógłbym po prostu poprzedzić nazwy schematów nazwami baz danych.

To był jeden z powodów, dla których zacząłem pracować z linq2sql. Nie wiem, czy EF jeszcze zezwolił na tę funkcję, ale pamiętam, że przeczytałem, że nie było to możliwe.

Banford
źródło
12

Jeśli twoja baza danych jest prosta i prosta, zrobi to LINQ to SQL. Jeśli potrzebujesz elementów logicznych / abstrakcyjnych na wierzchu swoich tabel, przejdź do Entity Framework.

Vintana
źródło
4
Entity Framework pozwala na warstwę abstrakcji górnej części bazy danych. Problem z wieloma Maperami OR dzisiaj (moim zdaniem) polega na tym, że zapewniają mapowanie 1 do 1 między tabelami i klasami. Model bazy danych nie zawsze odzwierciedla nasz sposób myślenia o nim w kategoriach modelu biznesowego.
senfo
Zabrakło miejsca. W każdym razie, w oparciu o to, co powiedziałem powyżej, twierdzę, że twoja odpowiedź nie jest kompletna.
senfo
7
Myślę, że to naprawdę zła rada. L2S jest dobry bez względu na prostotę lub złożoność bazy danych. Prawdziwą pułapką nie jest właściwe rozdzielenie obaw. Jeśli spróbujesz połączyć swoją warstwę biznesową i warstwę dostępu do danych, a do wszystkiego wykorzystasz obiekty Linqed up, zobaczysz ograniczenie L2S. Ale to jest problem w przypadku zbyt uproszczonego i monolitycznego projektu. L2S stanowi świetny DAL, a jeśli rozważenie zapytania i wytrwałości jest czymś innym niż reguły biznesowe, na dłuższą metę zaoszczędzisz sobie wielu problemów.
mattmc3
1
to mi nic nie mówi. Co jest proste w twoich warunkach?
PositiveGuy,
1
i co masz na myśli jako przykład „logicznej / abstrakcyjnej”. Tak, wiem, czym jest abstrakcja, ale przykład w twoim kontekście, proszę ... wytłumacz mi dokładnie to, co mówisz ... opisz to, nie mów mi tylko ogólnego slangu ... to wszystko w stosunku do mówcy te słowa, więc nie mam pojęcia, co TY przez to rozumiesz.
PositiveGuy,
8

Żadne z nich nie obsługuje jeszcze unikalnych typów danych SQL 2008. Różnica z mojej perspektywy polega na tym, że Entity nadal ma szansę zbudować model wokół mojego typu danych geograficznych w niektórych przyszłych wydaniach, a Linq na SQL, ponieważ jest porzucony, nigdy tego nie zrobi.

Zastanawiaj się, co słychać w nHibernate lub OpenAccess ...

John Dunagan
źródło
3
Obsługiwane typy danych przestrzennych SQL Server 2008 (Open Geospatial Consortium OGS) od Entity Framework 5. Obsługiwani byli także inni dostawcy (Devart dla Oracle). Zobacz msdn.microsoft.com/en-us/data/dn194325 .
subsci
6

Myślę, że jeśli chcesz szybko coś opracować bez dziwnych rzeczy pośrodku, a potrzebujesz obiektu, który ma byty reprezentujące twoje tabele:

Linq2Sql może być dobrym sojusznikiem, użycie go z LinQ uwalnia świetnie rozwijające się wyczucie czasu.

MRFerocius
źródło
4
„nie Dziwne rzeczy w środku”, ok, co przez to rozumiesz. Przykład „dziwnej rzeczy w środku”
PositiveGuy
Byłoby miło edytować lub usunąć tę odpowiedź, nie jest już użyteczna dla współczesnego rozwoju i może sprawić, że ludzie znajdą się na niewłaściwym torze.
Giulio Caccin
6

Pracuję dla klienta, który ma duży projekt korzystający z Linq-to-SQL. Kiedy projekt się rozpoczął, był to oczywisty wybór, ponieważ Entity Framework nie miał w tym czasie kilku głównych funkcji, a wydajność Linq-SQL była znacznie lepsza.

Teraz EF ewoluował i Linq-to-SQL nie obsługuje asynchronizacji, co jest doskonałe w przypadku wysoce skalowalnych usług. Czasami mamy ponad 100 żądań na sekundę i pomimo zoptymalizowania naszych baz danych, większość zapytań wciąż trwa kilka milisekund. Z powodu synchronicznych wywołań bazy danych wątek jest zablokowany i niedostępny dla innych żądań.

Myślimy o przejściu na Entity Framework, wyłącznie dla tej funkcji. Szkoda, że ​​Microsoft nie zaimplementował obsługi asynchronizacji w Linq-to-SQL (lub open source, aby społeczność mogła to zrobić).

Dodatek grudzień 2018 r .: Microsoft zmierza w kierunku .NET Core, a Linq-2-SQL nie obsługuje .NET Core, więc musisz przejść do EF, aby mieć pewność, że w przyszłości możesz migrować do EF.Core.

Jest także kilka innych opcji do rozważenia, takich jak LLBLGen . Jest to dojrzałe rozwiązanie ORM, które istnieje już od dawna i zostało udowodnione, że jest bardziej przyszłościowe niż rozwiązania danych MS (ODBC, ADO, ADO.NET, Linq-2-SQL, EF, EF.core).

Ramon de Klein
źródło
2

Linq-to-SQL

Jest dostawcą, który obsługuje tylko SQL Server. Jest to technologia mapowania służąca do mapowania tabel bazy danych SQL Server na obiekty .NET. Jest pierwszą próbą Microsoftu do ORM - Object-Relational Mapper.

Linq-to-Entities

To ten sam pomysł, ale przy użyciu Entity Framework w tle, podobnie jak ORM - ponownie od Microsoft, Obsługując wiele baz danych główną zaletą frameworku encji jest to, że programista może pracować na dowolnej bazie danych bez konieczności uczenia się składni, aby wykonywać dowolne operacje na różnych różnych bazach danych

Z mojego osobistego doświadczenia wynika, że ​​Ef jest lepszy (jeśli nie masz pojęcia o SQL), wydajność w LINQ jest nieco szybsza w porównaniu do EF z powodu języka LINQ napisanego w lambda.

Umang Patwa
źródło