Linq2SQL против EF в .net Framework 4.0

Question

Так какой же вердикт по этим двум продуктам сейчас?Похоже, я не могу найти что-либо относительно этой проблемы, ОСОБЕННО для VS2010 / .net 4.0

. В течение 3,5 дней большинство людей считают, что Linq2SQL умрет, когда появится .net 4.0, но он кажется живым ихорошо.

С другой стороны, EF 4.0, похоже, значительно улучшился.

Для меня большая часть моей работы до сих пор - это проекты малого и среднего размера, и моя компания переходит отVS08 до VS10 скоро.На что мне смотреть?Или на самом деле, стоит ли мне тратить время на изучение EF4.0 или лучше потратить время на изучение nHibernate?(Но вернемся к теме, меня действительно больше интересует Linq2Sql - EF.)

Наконец, в настоящее время я использую entlib / unity, какая структура более удобна для внедрения зависимостей / политик?

Заранее спасибо.

Answer 1

Вот несколько причин, почему Entity Framework (v4) лучше:

1 - L2SQL по существу устарел

2 - L2SQL не поддерживает отображение POCO, EFделает.

3 - EF обладает большей гибкостью (сначала код, сначала модель, сначала база данных).L2SQL имеет только 1.

4 - EF поддерживает SPROC -> отображение POCO

5 - EF имеет Entity-SQL, что позволяет вам вернуться к классическому ADO.NET при необходимости

6 - EF поддерживает наследование (TPT, TPH)

7 - EF идет рука об руку с шаблоном Repository и отложенным выполнением через IQueryable

8 - компоненты EF (ObjectSet, ObjectContext) легко смоделированы и допускают DI

. Я не могу думать ни о какой причине, почему новые проекты должны использовать L2SQL.

Некоторые могут сказать: «Ну, L2SQL хорош для небольших проектов, я могу перетащитьи брось и покончим с этим ".

Что ж, вы можете сделать это и с EF4, и в долгосрочной перспективе у вас будет больше гибкости / поддержки, если вы решите изменить / расширить свой проект.Так что это не оправдание.

HTH

Answer 2

Просто чтобы добавить к предыдущим ответам и комментариям (все трое получили +1 голос от меня):

a) Производительность : среда выполнения L2S более легкая, чем EF (из-за только одного слоя; EF имеет дело с двумя слоями модели и отображениями между ними). ​​

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

L2S также немного лучше выполняет оптимизацию запросов на стороне клиента; он исключает предикаты предложения where, которые могут быть оценены на стороне клиента, поэтому базе данных не нужно беспокоиться о них. Это означает меньше работы для оптимизатора SQL Server и меньший риск того, что вы получите «плохой» план выполнения.

b) L2S против L2E : L2S все еще немного лучше, чем L2E, при переводе запросов LINQ, использующих обычные методы CLR, в TSQL, особенно когда речь идет о DateTime и связанных с ним методах. L2E поддерживает более или менее те же вещи, но через свой собственный класс EntityFunctions: http://msdn.microsoft.com/en-us/library/system.data.objects.entityfunctions.aspx.

На мой взгляд, и L2S, и EF - отличный выбор , выберите тот, который вам удобнее, и охватите все, что вам нужно сейчас, и в течение разумного срока службы кода, который вы пишете. Прежде чем вы это узнаете, Microsoft, вероятно, объявит еще одну технологию доступа к данным. Кажется, они делают это каждые 3-5 лет ... :) DAO, RDO, ODBC, ADO, OLEDB, ADO.NET, типизированные наборы данных, ObjectSpaces, WinFS, L2S, EF, ... и т. Д. И т. Д. Код, который я написал 15 много лет назад против DAO все еще существует, в приложениях, которые все еще на рынке, и он все еще работает, несмотря на то, что DAO годами "мертва".

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

Answer 3

L2S никуда не денется.Команда VS прояснила это.Он не получит значительных улучшений, но все равно будет работать и будет отлично работать.

L2S великолепен и прост в использовании для небольших проектов с довольно простыми моделями данных.Для меня триггер, когда я выбираю EF вместо L2S, - это если у меня есть таблицы «многие ко многим», или мне нужно отобразить более сложные объекты на более чем одну таблицу.

Answer 4

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

На мой взгляд, ключевым моментом является то, делаете ли вы полностьюновый проект или работа с устаревшей БД.Я работаю с устаревшей БД, с некоторыми довольно своеобразными проектными решениями.Я хотел бы использовать EF, но он просто не смог отобразить эти особенности, в то время как L2S справился на отлично.

Например.Некоторые из FK содержали другие значения, кроме ключей для связанных строк - фактически удваивались как столбец FK / flag.

Кроме того, отображение наследования FK полностью не сработало с нашей БД, поэтому я выбрал плоскую модель L2S, чтобыполучить преимущества проверки типов и имен во время запроса, но прекратил создавать свой собственный слой отображения.

Все это ужасная боль, если это утешает MS, я также обнаружил, что NHibernate не в состояниизадача.По моему опыту, в реальном мире слишком много БД имеют такие проблемы, поэтому я рекомендую, чтобы EF не очень подходил для разработки в бурых полях.

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

Примечание: В Великобритании (по крайней мере), коричневыйразработка месторождения - это строительство домов на ранее разработанной земле.Развитие зеленых полей основывается на наших истощающихся ресурсах сельской местности.Я снова использовал здесь термины.

Answer 5

Мы только что перешли с VS 2008 на VS 2010 и с L2S на EF.

Несмотря на то, что мы используем EF очень похоже на L2S, мне приятно знать, что у меня есть гибкость, чтобы делать более продвинутые ORM в случае необходимости.

Тем не менее - для небольшого проекта - я, вероятно, все еще буду использовать L2S. Для средних и крупных проектов я бы использовал EF.

Также - EF выглядел как большая кривая обучения, потому что документация EF побудила нас начать исследовать некоторые шаблоны проектирования, такие как Unit Of Work, Repository, Dependency Injection. Однако я понял, что эти паттерны применимы как к L2S, так и к EF.

С точки зрения Nhibernate - мое исследование (т.е. просмотр SO) показывает, что последняя версия EF4.0 достаточно продвинута (поддержка POCO и т. Д.), Чтобы считаться конкурентоспособным продуктом.

Answer 6

Если вам подходят сторонние продукты, попробуйте использовать LinqConnect . Этот продукт позволяет использовать Linq to SQL (с некоторыми модификациями) с разными СУБД (Oracle, MySQL, PostgreSQL и т. Д.).
LinqConnect предлагает вам следующие функции, недоступные в L2S ранее:

• Модель-Первый подход
• Поддержка TPT и TPH
• Поддержка POCO
• Автоматическая синхронизация модели и базы данных без потери данных.

Что касается производительности, последний сравнительный тест на OrmBattle , наш поставщик является одним из лидеров.

Кроме того, все функции EF поддерживаются нашими провайдерами, специализирующимися на СУБД .