Linq 2 SQL или объекты Linq

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

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

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

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

Например, я недавно разрушил Платформу Объекта из проекта работы после работы с ним довольно единогласно за последние несколько недель, поскольку это не упрощало мои потребности, главным образом из-за:-

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

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

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

Дополнительные материалы для чтения (другой ТАК отправляет):
LINQ к SQL, мертвому или живому?

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

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

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

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

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

Для использования с Услугами передачи данных ADO.NET (который Вы упоминаете), Платформа Объекта является той, которая работает из поля. Если Вы хотите обновить данные с LINQ-SQL (через Услуги передачи данных ADO.NET), необходимо сделать некоторую работу для реализации IUpdatable. К счастью я вел блог об этом на этой неделе.

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

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

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

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

Оба techs имеют проблемы (NHibernate имеют проблемы также).

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

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

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

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

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

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

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

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

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

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

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

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

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

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