Чи LINQ для SQL мертвий?

Чи є якась причина продовжувати використовувати Linq для SQL, чи краще перейти до таких методів ORM, як EF, NHibernate тощо.

Ми використовуємо Linq до SQL у новому великому корпоративному додатку, який існуватиме довгий час. Мотивація цього нового корпоративного додатку полягає в тому, що програма звичайно написана на Visual Basic і оскільки Microsoft припинила підтримку, яку ми змусили переписати додаток. Здається, ми вже є, але на цей раз з нашим DAL (шаром доступу до даних).

Я вже читав цю статтю , але вона порівнюється лише зі слабкістю EF.

Якщо ви вже користуєтесь ним і не стикаєтесь із жодними труднощами, я б дотримувався цього в існуючих проектах.

Linq2SQL є досить приємним, але обмеженим, ORM - якщо ви хочете скласти карту ваших об'єктів більш складними способами, ніж основні, що надаються Linq2SQL, то ви збираєтеся застрягти. Microsoft виправила кілька помилок, коли вони вийшли з .net 4, але заявили, що не збираються витрачати ресурси на її розширення.

Я б сказав, якщо у вас досить простий проект, який, можливо, має обмежений термін експлуатації, то Linq2SQL - це гідний легкий вибір, якщо ви обережні, щоб не просочуватися залежностями до Linq2SQL повсюдно. Для нічого більшого я б пішов з чимось іншим (наприклад, NHibernate або EF), оскільки Linq2SQL - це майже безвихідь.

Він не мертвий, але Microsoft зараз зосереджена на Entity Framework.

Я використовував LINQ для SQL в невеликих проектах, і це дуже приємно як легкий рівень даних, і я б розглядав можливість використовувати його знову для подібних проектів. Сама реалізація LINQ справді хороша і до недавнього часу набагато краща, ніж проект LINQ NHibernate. Що стосується більшого проекту, в якому я використовував L2S, мені було важко придумати шаблон роботи, який був мені задоволений, через обмеження класу L2S "DataContext". Спроба реалізувати щось подібне до "Сеанс на запит" за допомогою L2S видається дуже важким або неможливим.

Я також не дуже розглядаю L2S як справжній ORM, оскільки він дійсно не дає вам багато варіантів картографування. Дизайн вашого класу дійсно повинен відповідати схемі вашої бази даних (таблиця за класом), інакше вона буде боротися з вами на кожному кроці шляху. Ще одна річ, яка мені не подобається в L2S, - це необхідність використовувати конкретні типи ( EntitySetі EntityRef) для обробки колекцій, посилань та ледачих завантажень. Це означає, що неможливо зберегти доменну модель ORM агностиком без додавання іншого шару абстракції.

Моя інша проблема з L2S - це виключна залежність від LINQ для генерування запитів. Постачальник LINQ дуже добре написаний і, як правило, створює пристойний SQL для більшості запитів, але я сумніваюся, що є більш складні запити, які не можуть бути добре виражені з LINQ. Використовуючи L2S, в основному ви повинні повернутися до виклику збережених процедур у цих випадках, тоді як (наприклад, NHibernate має декілька API (постачальник LINQ, QueryOver, HQL тощо), які можна використовувати, коли ви хочете більше контролювати створений SQL.

На захист L2S над NHibernate, набагато менше накладних витрат на отримання цього проекту та його виконання.

Він не мертвий, як це все ще працює, але якщо він не розвивається далі, то може бути сенс перейти до чогось іншого.

Однак якщо це працює для вашої програми, немає сенсу міняти заради зміни.

стабільніше, ніж мертвий імхо:

http://www.thinqlinq.com/default/LINQ-to-SQL-enhancements-for-2010.aspx

http://jonkruger.com/blog/2009/06/06/linq-to-sql-is-not-dead/

Вони спрямовували свої зусилля на вдосконалення до Entity Framework, де це дійсно потрібно для досягнення успіху цього продукту. Не чекайте нічого нового, крім сумісності та виправлення помилок на linq2sql на деякий час.

Цей сайт працює з цілою кількістю linq2sql, якщо я не помиляюся.

Це дивно, але я багато бачив цього фразування ("LINQ2SQL мертвий"), і я не впевнений, звідки це походить з *. Це так само, як і мертвий Windows XP. Microsoft припинила підтримку і створила щось нове (і, на мої очі, краще), але люди все ще вільні користуватися XP так само, як вони можуть безкоштовно використовувати Linq2SQL. Справді, я використовую Linq2SQL під час створення спеціальних модулів DotNetNuke. Однак з новими можливостями EF4, такими як розробка коду ( http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx ) важко знайти причини дотримуватися Linq2SQL. Я не бачу причин переглядати і оновлювати код, але для нового коду я не знаю, чому ви не хочете використовувати EF4.

* Чесно кажучи, я дуже… нав’язливий щодо семантики! Прошу вибачення, якщо це дратує оточуючих :)