LINQ to SQL или Entities на этом этапе?

Есть ли причина использовать LINQ to SQL или мне просто перейти к Entities?

Я вряд ли объективен (как упорный пользователь LinqToSql), но это ответит.

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

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

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

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

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

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

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

  //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);

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

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

В моих девелоперских проектах моя история всегда заключалась в следующем:

1. построить схему
2. построить объекты базы данных, которые работают со схемой
3. создать уровень данных, который общается с объектами базы данных
4. построить бизнес-уровень, который общается с уровнем данных

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

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

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

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