LINQ to SQL или Entities, на данный момент?

Я немного опаздываю в игру и решил потратить некоторое время на изучение LINQ. В качестве упражнения я собираюсь переписать приложение WebForms в MVC 2 (что также является новым для меня). Мне удалось найти несколько тем, касающихся LINQ здесь (Изучение LINQ, Руководство для начинающих по LINQ, Является ли LINQ to SQL Dead или Alive?), что вызвало интерес у Entities vs SQL к моему вниманию.

Тем не менее, потоки старше года, и я не могу найти окончательной информации о том, какая ORM предпочтительнее. Являются ли объекты более или менее LINQ to SQL 2.0 на данный момент? Его еще труднее использовать?

Есть ли какая-нибудь причина использовать LINQ to SQL, или я просто прыгаю в Entities? Приложения, которые я пишу у моего нынешнего работодателя, имеют длительный жизненный цикл (~ 10 лет), поэтому я пытаюсь выбрать лучшие доступные технологии.

Ответ 1

В недавнем посте о расширении NerdDinner, Scott Hanselman говорил об этом самом. Процитировать в конце:

Заключение

Там много вариантов для базы данных Доступ к .NET. Вы столкнетесь DataReaders в старых или высоко настраиваемых кода, но нет причин, по которым он не может спрятаться в репозитории и по-прежнему приятный в использовании. LINQ to SQL - это хорошо, легкий и быстрый и имеет десятки исправления ошибок в .NET 4, но Entity Рамки - это то, как они идут продвижение вперед.. Кроме того, Entity Framework 4 лучше, чем EF 3.5, поэтому я используя его для любых "больших, чем маленьких", проектов, которые я делаю, и у меня нет много проблем.

Конечно, у меня еще не было возможности поиграть с ним, но EF4, похоже, завоевал доверие многих профессионалов.

Ответ 2

Есть ли какая-нибудь причина использовать LINQ to SQL, или я должен просто прыгать в Entities?

Я едва ли объективен (как жесткий пользователь LinqToSql), но это ответственно.

Объект Реляционные технологии сопоставления - это попытки решить или смягчить несоответствие объектно-реляционного импеданса. Это мосты между двумя мирами - мир объектов и мир реляционных данных.

И кажется, что разработчики этих мостов вообще называют одну или другую, дома.

LinqToSql является ORM со стороны объекта. Он был разработан командой С# и позволяет использовать объекты для представления данных. В LinqToSql нет непротиворечивых строк, все запросы проверяются компилятором против сопоставления.

EF является ORM со стороны данных. Он был разработан командой ADO и позволяет использовать данные, представленные как объекты. В EF имеется много непрозрачных струн.

Запросы должны в конечном счете выполняться против базы данных, и компилятор не может подтвердить, что база данных, доступная во время выполнения, соответствует сопоставлению (true в ORM). Из-за этой реальности мира данных команда данных не оценивает гарантии компилятора так же, как и команда С#.

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

Например, загрузка Клиента с его ордерами.

  //linq to sql.
DataLoadOptions load = new DataLoadOptions();
load.LoadWith<Customer>(c => c.Orders);  //<-- strong typed
myDataContext.LoadOptions = load;

IQueryable<Customer> query = myDataContext.Customers
  .Where(c => c.CustomerId == 1);

  //entity framework
IQueryable<Customer> query = myObjectContext.Customers
  .Include("Orders")  // <-- opaque string
  .Where(c => c.Customer.Id == 1);

Ответ 3

Эта статья похожа на статью Гензельмана. Он сравнивает DataReader (который они называют "подключенным" доступом к данным), набрал DataSet ( "отключен" ), LINQ to SQL и Entity Framework. Подробные примеры кода приведены для всех подходов, а также плюсы и минусы каждого подхода.

Ответ 4

Я очень внимательно изучил обе технологии в начале 2009 года, и я прислушался к множеству грохотов о "надвигающейся смерти" LINQ-to-SQL. В конце концов, я по-прежнему выбрал LINQ-to-SQL над Entity Framework, потому что мне никогда не нравилось работать с ADO.NET, и EF слишком сильно напомнил мне об этом, потому что он был настолько тесно связан с базой данных.

В моих проектах разработки моя история всегда была:

построить схему
создать объекты базы данных, которые работают со схемой
создать слой данных, который говорит с объектами базы данных
создать бизнес-уровень, который говорит с уровнем данных

С EF мало что изменилось бы. С LINQ-to-SQL я смог полностью устранить шаг №2, чтобы слой данных напрямую разговаривал с базой данных, не беспокоясь о динамических высказываниях SQL или потенциальных уязвимостях инъекций. Кроме того, я также получил преимущество гораздо более простого процесса управления изменениями во время цикла разработки. Мне действительно все равно, что Microsoft "официальная" позиция, потому что я слышал о "нависшей смерти" WinForms уже около пяти лет, и она все еще вокруг.

Microsoft - это бизнес, прежде всего. Если они хотят остаться в бизнесе, они дадут клиенту то, что они желают, или же клиент найдет кого-то еще более желающего удовлетворить свои потребности. Если только для устаревших приложений, которые все еще используются в настоящее время, WinForms будет поддерживаться до тех пор, пока операционная система Windows все еще поддерживает приложения Windows 95. В том же ключе LINQ-to-SQL будет поддерживаться в той или иной форме. Пока он не будет полностью объединен с EF, где существующие приложения будут запускаться как изначально разработанные (или с модификацией разработчика минимальная), я считаю, что LINQ-to-SQL также должен оставаться в обозримом будущем.

Ответ 5

Я предлагаю идти с Entities или NHibernate, Linq очень тесно связывает базу данных с вашими объектами домена, которые затем используются вашим уровнем представления. Это приведет к плотной связи уровня представления с базой данных, которая, как правило, не рекомендуется.

Лично мне нравится Entity Framework 4.0, вы можете использовать запросы linq с ним и объекты POCO, которые вы сами кодируете. Он просто обрабатывает все данные базы данных /SQL для вас.