Linq 2 SQL или Linq Entities

Question

Я начинаю разрабатывать новое приложение, и меня интересует мнение людей о Linq2SQL или Linq2Entities и то, что они считают лучшей технологией для быстрой разработки.

Я также занимаюсь исследованием служб данных ADO.net.

Answer 1

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

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

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

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

Кроме этого, команды и структура казались прямыми и аккуратными, и причина, по которой я пошел с EF, была:

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

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

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

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

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

Answer 8

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

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

---

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

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

Answer 9

Никто не может сказать, что Вы безоговорочно что лучше.

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

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

Answer 10

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