Linq 2 SQL или Linq Entities

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

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

13.12.2008 03:10:22
11 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

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

8
13.12.2008 03:18:09
Linq2SQL допускает некоторые подклассы, но он не очень гибкий. Вы должны использовать один столбец как дискриминатор типа. Я хотел сделать это в иерархической таблице (где наличие fk в той же таблице показывает отношение к родителю в той же таблице), но не смог заставить его работать.
tvanfosson 13.12.2008 03:45:39
Это правда, потому что LINQ to SQL не был разработан с учетом подклассов, а был EF. Но это - наряду с другими функциями EF - добавляет сложности, а значит, и больших накладных расходов.
Boyan 13.12.2008 05:44:49
Вы должны иметь довольно плоский / скучный / простой дизайн таблицы, чтобы легко использовать любую из функций MS (строго типизированные TableAdapters, Linq2Sql и т. Д.)
user7116 3.02.2009 15:17:21

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

3
13.12.2008 03:16:39
Хотелось бы узнать больше о том, как вы расширили L2S
RobS 13.12.2008 06:57:29
Можно ли поделиться некоторыми вашими кодами, это очень ценно для нас
Mostafa 14.01.2010 20:22:33
Достаточное количество того, что я сделал с LINQ2SQL, можно найти в моем блоге: farm-fresh-code.blogspot.com
tvanfosson 14.01.2010 21:03:57

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

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

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

1
13.12.2008 03:27:13

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

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

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

Лично я рекомендую, чтобы кто-то, кто начинает, перешел прямо к SQL, и пропустил LINQ to SQL.

-1
13.12.2008 05:01:17
Тупик? Это? Я не совсем уверен ... reddevnews.com/blogs/weblog.aspx?blog=3016
KristoferA 13.12.2008 05:44:39
-1 не от меня, а ваш "настоящий SQL" - вы можете указать L2S на методы SPROC и UDF, чтобы использовать его в качестве DAL поверх жесткого слоя TSQL.
Marc Gravell♦ 13.12.2008 09:38:25
Привет, Марк, я не возражаю против "-" для инакомыслия. Ожидается:) ... Но зачем мне ставить L2S в качестве DAL вместо SPROC? Почему я не буду использовать Proc direct в своем коде? L2S - кормить детей ORM для начинающих. Я не вижу веских причин для его принятия. (А вот и еще «-»)
Cyril Gupta 13.12.2008 22:58:15
звучит для меня, как наркоман SQL чувствует угрозу и пытается принизить технологию, не изучив ее по-настоящему ...
naspinski 6.01.2009 07:05:11
Проверка ваших запросов во время компиляции слишком хороша для передачи. Я наркоман T-SQL, но мощь и простота L2S слишком велики, чтобы их списывать со счетов. Ты проиграл.
mattmc3 15.10.2010 01:32:02

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

0
13.12.2008 06:11:06

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

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

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

0
13.12.2008 07:54:12

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

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

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

3
23.05.2017 10:27:52

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

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

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

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

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

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

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

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

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

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

13
23.05.2017 12:08:35

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

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


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

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

0
27.10.2009 04:47:23

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

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

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

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

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

0
29.08.2009 11:57:56
Я с уважением не согласен. Как и (я полагаю) разработчики сайта, на котором вы размещены, поскольку StackOverflow использует L2S для своего механизма персистентности. Это не для всех, но у меня был большой успех в корпоративной среде с доступом к нескольким базам данных из ASP.NET. Если вы купили весь стек MS и все в порядке с анемичными объектами, привязанными к таблицам БД 1-к-1, L2S - отличное решение.
mattmc3 15.10.2010 01:27:31