2008-12-13 4 views
5

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

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

ответ

8

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

  • MS SQL Server как двигатель DB
  • разработки RAD
  • 1 - 1 отображение класса все требуется

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

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

+0

Linq2SQL допускает некоторые подклассы, но это не очень гибко. Вы должны использовать один столбец как дискриминатор типа. Я хотел сделать это в иерархической таблице (где наличие fk в той же таблице показывает связь с родителем в той же таблице), но не может заставить ее работать. – tvanfosson 2008-12-13 03:45:39

+0

Это правда, потому что LINQ to SQL не был разработан с учетом подкласса, и EF был. Но это - наряду с другими функциями EF - добавляет сложности, следовательно, большие накладные расходы. – Boyan 2008-12-13 05:44:49

+0

У вас должен быть довольно плоский/расточный/простой дизайн стола, чтобы легко использовать любые функции MS (строго типизированные TableAdapters, Linq2Sql и т. Д.) – user7116 2009-02-03 15:17:21

3

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

+0

Хотелось бы узнать больше о способах продления L2S – RobS 2008-12-13 06:57:29

+0

Возможно ли разделить часть вашего кода? Это ценно для нас. – Mostafa 2010-01-14 20:22:33

+0

. Справедливое количество того, что я сделал с LINQ2SQL, можно найти в моем блоге: http : //farm-fresh-code.blogspot.com – tvanfosson 2010-01-14 21:03:57

1

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

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

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

-1

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

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

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

Лично я рекомендую, чтобы кто-то, кто начинает, должен заканчивать прямо на SQL и давать LINQ to SQL промах.

0

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

0

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

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

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

3

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

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

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

2

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

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

Да, согласовано с Slace.

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

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

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

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

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

Дальнейшее чтение (другой SO пост):
Is LINQ to SQL Dead or Alive?

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

0

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

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


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

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

0

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

Do not use the Visual Studio 2008 LinqToSql O/R Designer

The drawbacks of adopting Linq To Sql

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

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