LINQ to SQL мертвий чи живий?

Просто коли я подружуся з LINQ to SQL, здається, що MS витягує килим з-під нього.

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

З моїх невеликих досліджень, EF є надмірним для простої роботи. Але після цього оголошення є сенс продовжувати використовувати LINQ для SQL?

Поза майбутнім LINQ to SQL, чи не є це загалом поганим сигналом? Враховуючи швидкість, з якою МС кидає біти об стінку, чи раціонально використовувати будь-який з нових бітів раніше? (і це ласкаво, для LINQ to SQL навряд чи рано!).

Що стосується моєї роботи LINQ to SQL, я думаю, що я перейшов до SubSonic!

Оновлення: Пара нових думок:

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) Вони не можуть "вбити" Linq-to-SQL, оскільки це вже є частиною .net. Що вони можуть зробити, це припинити додавати до нього функції. Це не заважає тисячам розробників, які вже використовують L2S, розширити його та вдосконалити. Деякі основні ділянки складно торкнутися, але вони вже тверді, і відсутні функції дизайнера можна легко застосувати .

2) Одна з сесій PDC EF показує, що вони засвоїли пару уроків з фіаско EFv1, і зараз вони копіюють та вставляють багато смаколиків із L2S у EF і роблять вигляд, що це нові речі EF. Іншими словами, версія 2 L2S щойно була "перемаркірована" EF.

3) LINQ як такий (Мовний інтегрований запит) - найкраща річ із нарізаного морозива, і його можна використовувати з багатьма іншими речами, крім L2S (Linq до об’єктів, Linq до сутностей, Linq до XML, Linq-до-чого-небудь ). Тож спроба групи DP вимусити [величезні маси] тих, хто приймає L2S, перейти до [менш популярної та в даний час недосконалої] системи Entity Framework, не є причиною не вивчати Linq.

Також перегляньте цю тему (саме це, на мою думку, частково спричинило пост у блозі Тіма): http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4061922&SiteID=1

Оновлення 1: Випуск обкладинки журналу Visual Studio від Роджера Дженнінгса від грудня 2008 року є гарним читанням на цю тему, з деякими порівняннями L2S та EF: http://visualstudiomagazine.com/features/article.aspx?editorialsid=2583

Оновлення 2: Андерс Хейлсберг процитував у Redmond Developer News заяву : " LINQ to SQL не мертвий. Я можу запевнити вас, що він не мертвий. Ніколи ніколи не зникає. Ми ніколи цього не робили і ніколи не будемо ".

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

У вашому питанні є неоднозначність, яку потрібно вирішити.

LINQ! = LINQ до SQL

Існує ціла купа технологій та постачальників LINQ:

• Посилання на SQL;
• Linq до юридичних осіб;
• Linq to Objects;
• Посилання на XML;

... і це лише ті, що від Microsoft. Є також постачальники послуг, що не входять до складу MS, включаючи NHibernate.

Допис у блозі, який ви пов’язали, говорить лише про Linq та SQL.

Ключова перевага LINQ полягає в тому, що ви можете вивчити та використовувати один синтаксис запиту та використовувати його повторно в різних технологіях.

Враховуючи це, я б припустив, що будь-яка сприйнята відсутність майбутнього для "Linq To SQL" є неактуальною, оскільки навички, які ви отримаєте при написанні запитів LINQ, у майбутньому будуть передані іншим інструментам.

Ми не вбиваємо LINQ до SQL. Ми оптимізуємо для EF, але LINQ to SQL точно не знищується :)

- Скотт / Microsoft.

Ви не тільки повинні вивчити Linq (System.Linq.Enumerable та System.Linq.Queryable), вам доведеться вивчити вдосконалення мови програмування для вашої мови .net.

До C # 3.0 вони включають:

• Методи розширення (статичні методи з цим ключовим словом для першого параметра)
• Виведені типи компілятора (var)
• Лямбда-синтаксис (який генерує анонімний метод або вираз залежно від контексту)
• Ініціалізатори
• Реалізація за замовчуванням властивості (скорочення)

Детальніше читайте тут .

У VB 9.0 є вбудована магія XML та багато іншого (багато подібних до наведеного вище списку для C #).

Детальніше читайте тут .

Я, чесно кажучи, не розумію, де в цій статті ви читали, що link2sql мертвий.

У повідомленні в блозі, на яке ви посилаєтесь, написано:

Ми слухаємо клієнтів щодо LINQ to SQL і будемо продовжувати вдосконалювати продукт на основі відгуків, які ми отримуємо від спільноти.

Для мене це читається як LINQ to SQL буде розроблено та підтримуватися в майбутньому. Цікаво, чому ви думаєте, що воно мертве?

Звичайно, я думаю, що вибір між LINQ to SQL, LINQ to Entities і LINQ to [insert Third Party ORM] тут забезпечує цілком здорову екосистему методологій рівня доступу до даних, яку може вибрати розробник програмного забезпечення. Сторонні постачальники, такі як NHibernate, LLBLGen і навіть Subsonic (не впевнені, чи збираються вони пропонувати постачальників LINQ), безумовно, зроблять конкуренцію кращою та цікавішою.

З огляду на це, для Microsoft буде абсолютно сумно відмовлятися від LINQ до SQL, тим більше, що він має хороші послідовники - навіть StackOverflow побудований на ньому.

Цікава публікація в блозі про це. І деяка пов’язана інформація про дописи Stackoverflow .

Основною суттю, здається, є коментарі, зроблені в блозі ado.net, в яких зазначається, що Entity Framework - це єдине, що отримує час для основних розробників для Visual Studio 2010 та Dot Net 4.

Моя відповідь - DUH. Ми всі це знаємо. Microsoft ще на PDC 2007 публічно заявила, що LINQ to SQL - це короткочасний випуск для SQL Server, оскільки іншої історії LINQ для SQL Server не існує. Він працює лише з SQL Server. Ви не можете написати LINQ постачальнику SQL - для нього немає моделі. Це була одноразова технологія, не розширювана.

Entity Framework - це ЄДИНИЙ спосіб від Microsoft створити постачальника LINQ. Entity Framework виявився досить суперечливим, але я думаю, що це частково пов’язано з тим, що LINQ to SQL сьогодні має кращий досвід програміста. Entity Framework схопить і перевершить LINQ для SQL, оскільки це інструмент ORM / Mapping майбутнього від Microsoft.

РЕДАГУВАТИ - Я щойно трохи детальніше написав про це у своєму блозі

EDIT2 - постачальник IQueryable - це НЕ те саме, що LINQ для постачальника SQL. Ви можете написати власного постачальника послуг IQueryable на все, що вам подобається. Ви не отримуєте підтримки дизайнера або покоління моделей. Немає жодної моделі дизайнера графічного інтерфейсу, яку б я знав для прив’язки до генерації моделі LINQ до SQL.

Я думаю, я насправді не бачу проблеми тут. Зі статті, на яку ви зв’язали:

Ми слухаємо клієнтів щодо LINQ to SQL і будемо продовжувати вдосконалювати продукт на основі відгуків, які ми отримуємо від спільноти.

Я щось пропускаю? Що створює враження, що LINQ для SQL мертвий після прибуття?

Скотт Гатрі сказав мені, що вони не будуть вбивати LINQ to SQL:

Опублікувати на LINQDev.com

Хтось пам’ятає VB6? Незалежно від того, чи вам це подобається особисто, Microsoft продала мільйони копій, а компанії витратили мільйони доларів, написавши мільйони рядків VB6. Що сталося далі?

• Ну, Microsoft все ще підтримує VB6 (на зразок - не IDE).
• А Microsoft все ще кажуть, що вони слухають клієнтів VB6 навіть зараз ( у вересні 09 ).
• Але чи задоволені клієнти VB6? Не з 2002 року , через 4 роки після запуску VB6.
• Чому ні? Шляхи оновлення для інвестицій коду до технології заміни, VB.Net, дорогі .

Тож просто розгляньте цей урок. Мені здається, підтримка LinqToSQL буде досить неприємною. Вони зобов'язані підтримувати його, оскільки він знаходиться в поточній платформі .NET. Але чи буде це в .NET 5, 6, 7 ...? Просто подумайте, наскільки це для вас важливо (наскільки я знаю, це для вас зовсім не важливо).

Можливо, вам не слід турбуватись вивченням Linq для SQL, але все ще існують сутності Linq, які вони будуть зберігати.

Див. Також http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx та коментарі там

Очевидно, що 2 ORM - це одна для багатьох у наборі інструментів Microsoft, але мені здається, що неправильна структура була обрана з усіх неправильних причин. Той факт, що команда C # зробила роботу, яку мала виконувати команда ADO.NET, за набагато коротший час і зробила роботу краще, важко проковтнути для команди ado.net. Не те, що я знаю внутрішню роботу двох фреймворків, але я думаю, було б набагато швидше оновити недоліки, які має linq2sql, до сутності.

Здається, тут задіяно занадто багато політики, і я думаю, що це дійсно зашкодить репутації asp.net, оскільки я не довіряю цій структурі Entity, що дасть нам такий самий зручний досвід, як Linq2sql. Команда ado.net також може навчитися деяким навичкам спілкування у команди asp.net mvc, оскільки роз'яснення проблеми в кращому випадку розмиті.

Було б цікаво дізнатися, як тут стоїть Скотт Гу та його команда MVC, оскільки більшість їх прикладів використовують Linq2Sql.

Завжди було трохи дивно, що з Linq 2 Sql та Entity Framework існували великі області перекриття. Я думаю, що єдиною причиною, через яку L2S коли-небудь потрапив до випуску .NET 3.5, було те, що існував великий сумнів у тому, що EF коли-небудь побачить світ. Тепер, коли вийшов EF1, нехай це буде дуже груба версія v1, у L2S більше не було потреби.

(ні, StingyJack, LINQ to SQL не використовує структуру сутності)

У всякому разі, я б не хвилювався. Тім заявляє, що вони слухають клієнтів щодо LINQ to SQL. Судячи з ентузіазму, який я бачив щодо L2S, клієнти (це ми) будуть говорити про свої думки.

І, як зазначає KristoferA, вони насправді не можуть "вбити" L2S, лише заморозити його. А L2S, після полірування, насправді не вимагає набагато подальшого розвитку. За умови наявності постачальника L2S будь-який прогрес у LINQ повинен бути доступний і в L2S. Тож вибір все одно буде за нами.

Наступна версія Windows Phone 7, кодова назва Mango, включає компактне видання SQL Server, доступне через Linq to SQL http://jesseliberty.com/2011/05/10/coming-in-mangosql-server-ce/