Переключение на LINQ

Question

Я планирую потратить время на изучение и использование LINQ to SQL, но после нескольких лет передового опыта, советующего НЕ встраивать SQL, мне трудно менять парадигмы.

Почему сейчас принято встраивать запросы в скомпилированный код? В некотором смысле это кажется мне шагом назад.

У кого-нибудь возникли проблемы с исправлением цикла запроса / компиляции / развертывания после перехода на LINQ?

Думаю, я все еще могу дождаться готовой Entity Framework.

Что ты думаешь?

Answer 1

Преимущество Linq перед Sql заключается в том, что он на самом деле не встраивает запросы в скомпилированный код - не совсем. Оператор Linq означает, что ваш код .Net фактически имеет логику, необходимую для построения встроенного оператора Sql, а не необработанного Sql.

Действительно имеет смысл иметь .Net-код, который конвертируется непосредственно в Sql для выполнения, а не длинный список sprocs со связанной документацией. Путь Linq гораздо проще поддерживать и улучшать.

Не думаю, что я бы переключил существующий проект на Linq - на самом деле это замена всего уровня данных, и он может изменить способ доступа к этому уровню. Если вы не переключаетесь с очень похожей модели, цена будет слишком высокой для любых потенциальных выгод.

Настоящая сила Linq to Sql заключается в быстром создании новых приложений - это позволяет очень быстро создавать код уровня данных.

Answer 2

Я согласен с вашей точкой зрения, это действительно кажется шагом назад ...

На самом деле, я бы, вероятно, отказался от LINQ to SQL и больше посмотрел бы на LINQ to Entities, ваши сущности моделируют вашу концептуальную модель данных, и я лично чувствую себя более комфортно встраивая запросы в концептуальную модель в мой код. Фактическая физическая модель абстрагируется от вас структурой сущности.

В этой ссылке (извините за каламбур) обсуждается LINQ to Entities и Entity Framework: http://msdn.microsoft.com/en-us/library/bb386992.aspx

В этой интересной статье обсуждаются плюсы и минусы обоих подходов: http://dotnetaddict.dotnetdevelopersjournal.com/adoef_vs_linqsql.htm

Редактировать Еще одна мысль: если вы не хотите ждать EF, взгляните на NHibernate, вы также можете LINQ к этому ... См. http://www.hookedonlinq.com/LINQToNHibernate.ashx

Answer 3

Вы должны думать о LINQ to SQL как об абстракции над написанием SQL непосредственно самостоятельно. Если вы можете обдумать это, тогда вы сделали шаг в правильном направлении. Вам также необходимо отказаться от некоторых давних убеждений, таких как скомпилированные sprocs, всегда быстрее, и учетные записи SQL не должны иметь привилегий чтения / записи данных.

Я обнаружил, что можно начать постепенное перемещение существующих решений в направлении LINQ to SQL, если имеется четкий DAL, и вы просто меняете реализацию, не влияя на контракт, который она может иметь с потреблением кода. Списки ссылок являются простым кандидатом, поскольку они малоэффективны, наборы данных только для чтения. Главное, что вам нужно помнить, если модернизация - это потенциальные неоднозначные имена классов, если вы уже вручную закодировали их для моделирования базы данных.

Учитывая ретроспективность внедрения LINQ to SQL в большое предприятие (начиная с CTP-дней), я бы сделал это снова в одно мгновение. Это не идеально, и есть проблемы, но есть огромные преимущества, особенно когда речь идет о скорости разработки и удобства обслуживания. Это новая парадигма и, безусловно, определенно шаг вперед.

Answer 4

Я не думаю, что это встраивание SQL в ваш код, как встраивание имени Stored Proc в ваш код. Чаще всего изменение вашего Proc в любом случае подразумевает изменение вашего кода. Например, вам обычно нужно добавить новый параметр in / out или обновить метод получения / установки для ссылки на новый столбец.

То, что он делает, это устраняет большую часть трудоемкой работы по написанию вдвое большего количества кода для выравнивания свойств и методов в вашем коде с процедурами и столбцами в вашей БД.

Answer 5

Существует реализация LINQ to SQL не только для баз данных SQL Server, поэтому разработчики, не являющиеся SQL Server, также могут воспользоваться преимуществами этого эффективного ORM. Мы уже добавили поддержку уровня запросов LaodWith () и расширили обработку ошибок. Также мы планируем поддерживать все три модели наследования (TPH, TPT, TPC) и генерацию полей ключей. Вы можете найти список поддерживаемых баз данных здесь