Czy LINQ to SQL jest martwy czy żywy?

Kiedy zaprzyjaźniam się z LINQ to SQL, wydaje się, że MS wyciąga spod niego dywanik.

http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx

Z moich badań wynika, że ​​EF to przesada w przypadku prostej pracy. Ale czy po tym ogłoszeniu warto nadal używać LINQ to SQL?

Czy poza przyszłością LINQ to SQL nie powoduje to po prostu wysyłania złego sygnału? Biorąc pod uwagę szybkość, z jaką MS rzuca bity o ścianę, czy rozsądne jest wczesne użycie któregokolwiek z nowych bitów? (i to jest miłe, na LINQ to SQL nie jest za wcześnie!).

Myślę, że do mojej pracy z LINQ to SQL zmierzam do SubSonic!

Aktualizacja: kilka nowych opinii:

http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx

http://codebetter.com/blogs/david.hayden/archive/2008/10/31/linq-to-sql-is-dead-read-between-the-lines.aspx

1) Nie mogą "zabić" Linq-to-SQL, ponieważ jest już częścią frameworka .net. To, co mogą zrobić, to przestać dodawać do niego funkcje. Nie przeszkadza to tysiącom programistów, którzy już używają L2S, przed rozszerzaniem go i ulepszaniem. Niektóre kluczowe obszary są trudne do dotknięcia, ale są już solidne, a brakujące funkcje projektanta można łatwo przykręcić .

2) Jedna z sesji PDC EF pokazuje, że wyciągnęli kilka lekcji z fiaska EFv1 i teraz kopiują i wklejają wiele gadżetów z L2S do EF i udają, że to nowe rzeczy EF. Innymi słowy, wersja druga L2S została właśnie „przemianowana” EF.

3) LINQ jako taki (Language Integrated Query) jest najlepszą rzeczą od czasu pokrojonych lodów i może być używany z wieloma innymi rzeczami niż L2S (Linq do obiektów, Linq do encji, Linq do XML, Linq-to-cokolwiek ). Tak więc próba grupy DP zmuszenia [ogromnych rzesz] użytkowników L2S do [mniej popularnych i obecnie wadliwych] Entity Framework nie jest powodem, aby nie uczyć się Linq.

Zobacz także ten wątek (który moim zdaniem częściowo wywołał post na blogu Tima): http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4061922&SiteID=1

Aktualizacja 1: Publikacja z okładki magazynu Visual Studio Magazine z grudnia 2008 r. Autorstwa Rogera Jenningsa to dobra lektura na ten temat, z niektórymi porównaniami L2S i EF: http://visualstudiomagazine.com/features/article.aspx?editorialsid=2583

Aktualizacja 2: Anders Hejlsberg był cytowany w Redmond Developer News jako powiedzenie „ LINQ to SQL nie jest martwy. Zapewniam, że nie jest martwy. Nic nigdy nie odchodzi. Nigdy tego nie robiliśmy i nigdy nie będziemy ”.

http://reddevnews.com/blogs/weblog.aspx?blog=3016

Twoje pytanie jest niejednoznaczne, które należy rozwiązać.

LINQ! = LINQ to SQL

Istnieje cała masa technologii i dostawców LINQ:

• Linq na SQL;
• Linq do Entities;
• Linq to Objects;
• Linq na XML;

... a to tylko te od Microsoft. Są też dostawcy spoza MS, w tym NHibernate.

Wpis na blogu, do którego utworzyłeś link, dotyczy tylko Linq do SQL.

Główną zaletą LINQ jest to, że możesz uczyć się i używać jednej składni zapytania i używać jej ponownie w wielu technologiach.

Biorąc to pod uwagę, sugerowałbym, że jakikolwiek zauważony brak przyszłości dla „Linq To SQL” jest nieistotny, ponieważ umiejętności zdobyte podczas pisania zapytań LINQ będą w przyszłości przenoszone na inne narzędzia.

Nie zabijamy LINQ to SQL. Optymalizujemy pod kątem EF, ale LINQ to SQL zdecydowanie nie jest zabijany :)

- Scott / Microsoft.

Nie tylko powinieneś nauczyć się Linq (System.Linq.Enumerable i System.Linq.Queryable), ale także nauczyć się rozszerzeń języka programowania dla twojego języka .net.

W C # 3.0 są to:

• Metody rozszerzające (metody statyczne ze słowem kluczowym this na pierwszym parametrze)
• Typy wywnioskowane przez kompilator (var)
• Składnia lambda (która generuje anonimową metodę lub wyrażenie w zależności od kontekstu)
• Inicjatory
• Domyślna implementacja właściwości (skrót)

Przeczytaj więcej tutaj .

W VB 9.0 jest trochę wbudowanej magii XML i wiele innych rzeczy (wiele z nich jest podobnych do powyższej listy dla C #).

Przeczytaj więcej tutaj .

Naprawdę nie rozumiem, gdzie w tym artykule przeczytałeś, że link2sql nie żyje.

W poście na blogu, do którego utworzyłeś łącze, jest napisane:

Słuchamy klientów w zakresie LINQ to SQL i będziemy nadal rozwijać produkt w oparciu o opinie, które otrzymujemy również od społeczności.

Dla mnie to czyta jak LINQ to SQL będzie rozwijane i obsługiwane w przyszłości. Zastanawiam się, dlaczego myślisz, że jest martwy?

To prawda, myślę, że wybór między LINQ to SQL, LINQ to Entities i LINQ to [wstaw ORM innej firmy] zapewnia tutaj doskonale zdrowy ekosystem metodologii warstwy dostępu do danych, spośród których może wybierać programista. Zewnętrzni dostawcy, tacy jak NHibernate, LLBLGen, a nawet Subsonic (nie jestem pewien, czy zamierzają zaoferować dostawców LINQ), z pewnością sprawią, że konkurencja będzie lepsza i ciekawsza.

Biorąc to pod uwagę, Microsoft będzie całkowicie smutny porzucić LINQ to SQL, zwłaszcza, że ​​ma on dobrych obserwatorów - nawet StackOverflow jest na nim zbudowany.

Ciekawy wpis na blogu o tym. I kilka powiązanych informacji na temat postów Stackoverflow .

Wydaje się, że podstawowym celem są komentarze na blogu ado.net, które stwierdzają, że Entity Framework jest jedyną rzeczą, która zyskała czas dla programistów Visual Studio 2010 i Dot Net 4.

Moja odpowiedź brzmi - DUH. Wszyscy to wiedzieliśmy. Microsoft powiedział publicznie podczas PDC 2007, że LINQ to SQL było krótkoterminowym wydaniem dla SQL Server, ponieważ nie było innej historii LINQ dla SQL Server. Działa tylko z SQL Server. Nie można napisać dostawcy LINQ to SQL - nie ma dla niego modelu. To była jednorazowa technologia, której nie można było rozszerzyć.

Entity Framework to JEDYNY sposób firmy Microsoft na tworzenie dostawcy LINQ. Entity Framework okazał się dość kontrowersyjny, ale myślę, że częściowo wynika to z faktu, że LINQ to SQL ma dziś lepsze doświadczenie programisty. Entity Framework będzie przechwytywać i przewyższać LINQ to SQL, ponieważ jest to narzędzie ORM / Mapping przyszłości firmy Microsoft.

EDYCJA - właśnie napisałem nieco bardziej szczegółowo na moim blogu

EDIT2 - IQueryable Provider - NIE jest tym samym, co dostawca LINQ to SQL. Możesz napisać własnego dostawcę IQueryable na cokolwiek chcesz. Nie masz wsparcia projektanta ani generowania modelu. Nie ma modelu projektanta GUI, o którym wiem, do powiązania z generowaniem modelu LINQ to SQL.

Chyba nie widzę tutaj problemu. Z artykułu, który podałeś:

Słuchamy klientów w zakresie LINQ to SQL i będziemy nadal rozwijać produkt w oparciu o opinie, które otrzymujemy również od społeczności.

Czy coś mi brakuje? Co sprawia wrażenie, że LINQ to SQL jest martwy w momencie przybycia?

Scott Guthrie powiedział mi, że nie zabiją LINQ to SQL:

Opublikuj na LINQDev.com

Czy ktoś pamięta VB6? Niezależnie od tego, czy go osobiście nienawidzisz, czy kochasz, Microsoft sprzedał miliony kopii, a firmy wydały miliony dolarów na napisanie milionów wierszy VB6. Co stało się potem?

• Cóż, Microsoft nadal obsługuje VB6 (w pewnym sensie - nie IDE).
• A Microsoft nadal twierdzi , że nawet teraz ( we wrześniu 09 ) słucha klientów VB6 .
• Ale czy klienci VB6 są zadowoleni? Nie od 2002 roku , 4 lata po premierze VB6.
• Dlaczego nie? Ścieżki uaktualnienia inwestycji w kod do technologii zastępczej VB.Net są drogie .

Więc rozważ tę lekcję. Wydaje mi się, że obsługa LinqToSQL będzie raczej niechętna. Są zobowiązani do wspierania go, ponieważ jest w obecnym frameworku .NET. Ale czy będzie w .NET 5, 6, 7 ...? Pomyśl tylko, jak bardzo to dla ciebie ważne (z tego co wiem, nie ma to dla ciebie żadnego znaczenia).

Może nie powinieneś zawracać sobie głowy nauką Linq na SQL, ale nadal istnieją jednostki Linq, które zachowają.

Zobacz także http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx i zamieszczone tam komentarze

Oczywiste jest, że 2 ORMy to jeden do wielu w zestawie narzędzi Microsoftu, ale wydaje mi się, że z niewłaściwych powodów wybrano niewłaściwą strukturę. Fakt, że zespół C # wykonał zadanie, które zespół ADO.NET miał wykonać w znacznie krótszym czasie i wykonał swoją pracę o wiele lepiej, jest trudny do przełknięcia dla zespołu ado.net. Nie znaczy to, że znam wewnętrzne działanie dwóch frameworków, ale myślę, że znacznie szybciej byłoby zaktualizować niedociągnięcia linq2sql do frameworka jednostki.

Wydaje się, że w grę wchodzi zbyt dużo polityki i myślę, że to naprawdę zaszkodzi reputacji asp.net, ponieważ nie ufam, że struktura Entity zapewni nam równie przyjazne dla użytkownika doświadczenie jak Linq2sql. Zespół ado.net mógłby również nauczyć się pewnych umiejętności komunikacyjnych od zespołu asp.net mvc, ponieważ wyjaśnienia dotyczące problemu są w najlepszym przypadku niejasne.

Fajnie byłoby dowiedzieć się, co stoi tutaj Scott Gu i jego zespół MVC, ponieważ większość ich przykładów używa Linq2Sql.

Zawsze było trochę dziwne, że w Linq 2 Sql i Entity Framework występowały duże obszary nakładania się. Myślę, że jedynym powodem, dla którego L2S pojawił się w wersji .NET 3.5, była duża wątpliwość, czy EF kiedykolwiek ujrzy światło dzienne. Teraz, gdy EF1 wyszedł, wszystko, czy to bardzo szorstka wersja v1, nie było już potrzeby L2S.

(nie, StingyJack, LINQ to SQL nie używa struktury jednostki)

W każdym razie nie martwiłbym się. Tim stwierdza, że ​​nasłuchują klientów dotyczących LINQ to SQL. Sądząc po entuzjazmie, jaki widziałem dla L2S, klienci (czyli my) będą mówić, co myślą.

I, jak wskazuje KristoferA, nie mogą faktycznie „zabić” L2S, a jedynie go zamrozić. A L2S, po wypolerowaniu, tak naprawdę nie wymaga dalszego rozwoju. Po wdrożeniu dostawcy L2S wszelkie postępy w LINQ powinny być również dostępne w L2S. Więc wybór nadal będzie nasz.

Następna wersja Windows Phone 7, nazwa kodowa Mango, zawiera SQL Server Compact Edition dostępne przez Linq do SQL http://jesseliberty.com/2011/05/10/coming-in-mangosql-server-ce/