Подтвердить что ты не робот

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

Итак, каков теперь вердикт по этим двум продуктам? Кажется, я ничего не могу найти по этой проблеме SPECIFICALLY для VS2010/.net 4.0

Назад........ 3.5 дня. Большинство людей считают, что Linq2SQL будет мертв, когда появится .net 4.0, но кажется живым и здоровым.

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

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

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

Спасибо заранее.

4b9b3361

Ответ 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 идет рука об руку с шаблоном репозитория и отложенным исполнением через IQueryable

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

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

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

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

НТН

Ответ 2

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

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

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

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

b) L2S vs 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, является постоянно движущейся целью...

Ответ 3

L2S никуда не денется. Команда VS сделала это ясно. Это не будет иметь существенного улучшения, но оно все равно будет работать и прекрасно работать.

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

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

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

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

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

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

Ответ 6

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

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

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

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