Сущности Linq 2 SQL или Linq

Я большой поклонник LINQ to SQL, если вы отвечаете следующим требованиям к дизайну:

• MS SQL Server как движок БД
• Разработка RAD
• 1–1 сопоставление классов - это все, что требуется

Я не очень много работал с Entity Framework, но из того, что я знаю и что я сделал, так это то, что он не имеет такой хорошей производительности при создании из той же базы данных, что и LINQ to SQL.

Более низкая производительность связана с природой Entity Framework, она использует ADO, а не конкретных поставщиков для сервера базы данных, который вы используете.

Да, согласен со Слэйсом.

Просто будьте осторожны с выбранной вами структурой, чтобы убедиться, что она соответствует всем вашим потребностям.

Например, я недавно исключил Entity Framework из рабочего проекта после того, как поработал с ним довольно солидно в течение последних двух недель, поскольку он не удовлетворил мои потребности, в основном из-за: -

1. вещи, которые нельзя делать в Linq to Entities (например, сопоставление с типами перечисления .net (grr) и усугубление получения NotSupportedException почти на каждом шагу, если вы пытаетесь проявить фантазию в своем операторе запроса linq, вызывая вызовы функций или методов (см. ссылку)) .
2. Отсутствие встроенной отложенной загрузки (я понимаю, что есть такие инструменты, как EF Lazy LoadGen, чтобы облегчить это, но я не хотел включать это).

В остальном команды и фреймворк казались простыми и аккуратными, и причина, по которой я выбрал EF, заключалась в следующем:

1. Я считал, что EF больше ориентирован на развитие предприятий, и думал, что L2S был больше для любителей и был ограниченным фреймворком. Однако с дальнейшим пониманием и лично, не нуждаясь ни в чем в EF, я не мог сделать с L2S, я доволен L2S. Особенно, если это подходит для stackoverflow, масштабируемость и эффективность для меня покрыты.
2. Вариант для нескольких СУБД '(однако я еще не видел этого в действии)
3. Ходили слухи, что Microsoft прекращает поддержку и инвестиции в Linq to SQL.
4. Мне нравится тот факт, что вы можете обновлять таблицы и изменения БД в EF .edmx без необходимости удалять существующую модель схемы (что вы вынуждены делать в Linq to SQL). Хотя это не очень раздражает, если вы не настроили какие-либо свойства в своей схеме L2S (.dbml).

Дальнейшее чтение (еще одно сообщение SO):
Живой или мертвый LINQ to SQL?

Я хотел бы выбрать EF, я действительно не знаю, что делать с отключением L2S и EF, и если L2S действительно мертвый утенок, пожимайте плечами. По общему признанию, моя основная проблема с EF - это NotSupportedException - я мог бы обойти ленивую загрузку, если бы мог выполнять вызовы методов в linq, не получая этого ...

Я бы сказал, что для простой или умеренной схемы базы данных Linq2SQL работает очень хорошо, и ее проще настроить и использовать. Это то, что я использую для своего ORM с некоторыми небольшими корректировками через частичные классы для поддержки проверки и авторизации / аудита. Я использую дизайнер DBML и добавляю свои таблицы / отношения. Я изменяю DataContext, чтобы сделать его абстрактным и построить конкретную реализацию, которая позволяет мне предоставлять реализации моих функций / хранимых процедур с табличными значениями (которые отображаются в контексте данных как методы), которые предоставляют перехватчики для аудита и авторизации. Я реализую частичные методы в классах сущностей для OnValidate и OnLoad, чтобы выполнять как проверку, так и авторизацию на уровне таблицы. Я считаю, что это почти все, что мне нужно. В последнее время я определял интерфейс и оболочку для конкретного контекста данных, чтобы позволить мне имитировать его в своих модульных тестах.

Для использования со службами данных ADO.NET (о которых вы упомянули) Entity Framework работает из коробки. Если вы хотите обновить данные с помощью LINQ-to-SQL (через ADO.NET Data Services), вам нужно проделать некоторую работу для реализации IUpdatable. К счастью, я писал об этом на этой неделе.

Мои общие мысли между ними изложены здесь, но с тех пор я немного смягчился, см. здесь.

По сути, на данный момент я предпочитаю LINQ-to-SQL, но я ожидаю, что EF будет более пригодным для использования в следующей версии. Поэтому я работаю над тем, чтобы LINQ-to-SQL работал с ADO.NET Data Services.

Я думаю, что Linq 2 Sql - отличный выбор. Несколько моментов:

• Это действительно быстро, я помню, как читал сообщение в блоге по адресу Лакомые кусочки производительности Рико Мариани во время бета-тестирования L2S, где он измерил, что он почти такой же быстрый, как старый добрый ADO.Net, и это было во время его бета-тестирования.
• Вы можете выполнять как запросы linq, так и работать с хранимыми процедурами и старым добрым sql, если вам это нравится, и при этом получать данные для сопоставления объектов, выполненных за вас.
• Тот факт, что Stackoverflow использует L2S, доказывает, что он может работать на крупномасштабном веб-сайте.
• Он намного легче, чем Entity Framework, что и хорошо, и плохо, в зависимости от того, что вам нужно. В общем, если ваши потребности не особо продвинуты, вы можете быстро решить любую проблему.

Я голосую за Linq-to-SQL. Он соответствует вашему сценарию быстрого развития; легко начать, легко использовать. Вдобавок он генерирует хорошие / эффективные SQL-запросы из выражений Linq.

Linq-to-Entities неуклюж, если вы попытаетесь использовать любую из `` расширенных '' функций, которые должны отличать его от L2S, вам придется начать редактировать файл модели EDMX с помощью редактора XML (вы скоро запустите в «ограничения» в конструкторе, где единственным обходным путем / решением, рекомендованным Microsoft, является использование редактора XML для ручного запуска EDMX). Вдобавок к этому он имеет тенденцию генерировать действительно плохие / неэффективные SQL-запросы.

Microsoft заявляет, что следующая версия Entity Framework будет намного лучше и будет поддерживать все преимущества L2S. Однако следующая версия не будет выпущена в ближайшее время, так что до тех пор L2S - ваш лучший выбор.

Я бы рекомендовал поискать решения для ORM сторонних разработчиков. nHibernate - отличное решение, в котором есть все плюсы обеих этих фреймворков, а также многое другое. Да, это более крутая кривая обучения, но беглый nHibernate помогает в этом. Это того стоит.

Никто не может сказать Вам определенно что лучше.

У обоих техников есть проблемы (у NHibernate тоже есть проблемы).

Я использую Linq-to-SQL и очень доволен этим. На мой взгляд проблем в Linq-to-SQL меньше, чем в EF ^ _ ^.

Это довольно старый вопрос, но меня беспокоит поддержка LinqToSql среди самых популярных ответов. У LinqToSql есть существенные недостатки.

Не используйте Visual Studio 2008 LinqToSql O / R Designer

Недостатки перехода на Linq To Sql

Тем не менее, у EntityFramework есть и существенные недостатки.

Доступны гораздо, намного лучшие варианты (на данный момент лучшим вариантом является NHibernate).

Мы думали, что L2S великолепен, пока не попробовали делать обновления. Тогда это было жалко. Мой коллега выполнял большую часть этой работы, а я занимался другими делами. Он рассказал об EF и о том, как чрезмерная настраиваемость делает его беспорядочным в использовании.

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

Мне любопытно, на основании чего этот ответ был отклонен против. В нем описывается реальный опыт, обсуждается альтернативная стратегия и относительный успех этого подхода. Голосование против ответов предназначено для ответов, которые вводят в заблуждение, фактически неверны или просто троллинг.

Так получилось, что я изменил свою позицию в отношении EF против L2S, но это не меняет того факта, что отрицательное голосование просто потому, что оно выражает мнение, отличное от вашего, является инфантильным и полностью противоречит духу StackOverflow.

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

Я думаю, что LINQ TO SQL следует принимать только тем, кто сильно зависит от уровней абстракции фреймворка и не имеет времени / энергии / желания заниматься SQL.

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

Лично я рекомендую тем, кто только начинает, сразу перейти к SQL и пропустить LINQ to SQL.