linq to sql vs ado.net entity

Если я использую SQL Server в качестве моей службы базы данных, есть ли веские основания смотреть на LINQ to Entities над Linq to SQL?linq to sql vs ado.net entity

источник

2010-01-29 Ciel

Дубликат много, много, много раз: http://stackoverflow.com/questions/8676/entity-framework-vs-linq-to-sql http://stackoverflow.com/questions/364740/linq -2-sql-or-linq-объекты http://stackoverflow.com/questions/264175/entity-framework-linq-to-sql-conflict-of-interest и т. Д. И т. Д. И т. Д. –

Linq to SQL больше не активно развивается - они фокусируют свои ресурсы на Entity Framework. Кроме того, EF намного более надежна и позволяет использовать несколько более сложных сценариев, которые были упущены в Linq to Sql.

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

источник

2010-01-29 18:20:57

L2S был расширен (некоторые) в .NET 4. –

@Craig: какие были улучшения для L2S? –

@John Saunders http://damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40 –

Linq to SQL достаточно хорош, если вам нужно только одно-однозначное сопоставление между вашими классами и таблицами, подумайте об этом как о «объектной» версии наборов данных.

EF позволяет выполнять намного более сложные отображения.

В долгосрочной перспективе Microsoft подталкивает всех к EF, однако EF более сложна в использовании. До тех пор, пока корабли .net 4 очень сложно выполнять разработку тест-драйвов с помощью EF.

Если вы собираетесь скрыть весь доступ к данным за набором интерфейсов и создать объекты домена самостоятельно на основе строк, которые вы получаете из базы данных, то Linq to SQL является хорошим вариантом в краткосрочной перспективе. Но вы, , можете отправить в EF в долгосрочной перспективе.

Если вы хотите, чтобы сопоставить объекты домена в базе данных с помощью ОРМ, то EF является лучшим объектом, но также и рассмотреть nhibernate

Если вы вернетесь через несколько лет времени ответа на свой вопрос будет EF, однако не ясна в настоящее время ...

источник

2010-01-29 18:28:18

Это зависит от того, как вы делаете TDD. Если вы выполняете модульные тесты с реальной базой данных, то этого недостатка не существует с EF. –

Ответ на вопрос на самом деле NHibernate - к сожалению, это не вариант для некоторых магазинов. –

@John - ваши модульные тесты не должны полагаться на базу данных, если вы на самом деле не проверяете уровень доступа к данным. Он медленный и нарушает всю идею тестирования в изоляции/ –

есть так много веских причин, чтобы выбрать Entity Framework над LinqToSql, но вы должны только один:

Microsoft предпочел бы использовать Entity Framework , Microsoft выделяет значительную часть ресурсов разработки ORM за EF. Это их будущая дорога.

К сожалению, EF 3.5 был значительным шагом назад от LinqToSql несколькими способами, поэтому Microsoft действительно подтолкнула многих людей, которые хотели использовать EF обратно в LinqToSql. С EF 4.0 EF не полностью эквивалентна функции LinqToSql, но она намного ближе.

EF 4.0 предлагает множество функций, которые LinqToSql в настоящее время не поддерживает и, вероятно, никогда не будет.

Держитесь подальше от EF 3.5. Если вы хотите ORM для .NET 3.5, используйте NHibernate. Для .NET 4.0 выберите между NHibernate и Entity Framework. На самом деле нет хорошей причины для использования LinqToSql с .NET 4.0.

источник

2010-01-29 20:31:57

linq to sql vs ado.net entity

ответ

Смежные вопросы