Entity Framework vs LINQ to SQL

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?

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

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.

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.

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.

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ż:

• LINQ To SQL Vs Entity Framework
• Różnica między LINQ a SQL i Entity Framework
• Entity Framework vs LINQ TO SQL

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

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.

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.

Dobre porównanie można znaleźć 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

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.

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.

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.

Ż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 ...

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.

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).

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.