LINQ к SQL или Объектам, в этой точке?

Эта статья похожа на статью Хансельмана. Он сравнивает 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 будет продолжать поддерживаться в той или иной форме. До тех пор, пока его не удастся плавно интегрировать в EF, где существующие приложения будут работать в первоначальном виде (или с минимальными изменениями разработчиков), я считаю, что LINQ-to-SQL также останется в обозримом будущем.

В недавнем сообщении о расширении NerdDinner Скотт Хансельман говорил именно об этом. Цитата в конце:

Заключение

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

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

Есть ли смысл использовать 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);

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

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