LINQ to SQL или Entities, на данный момент? - PullRequest
11 голосов
/ 04 июня 2010

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

Темам уже более года, и я не могу найти какой-либо определенной информации о том, какой ORM предпочтительнее. Является ли Entities более или менее LINQ to SQL 2.0 на этом этапе? Это еще сложнее в использовании?

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

Ответы [ 5 ]

7 голосов
/ 04 июня 2010

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

Заключение

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

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

5 голосов
/ 05 июня 2010

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

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

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

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

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

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

Запросы должны в конечном итоге выполняться для базы данных, и компилятор не может подтвердить, что база данных, доступная во время выполнения, соответствует отображению (true в любом 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);
3 голосов
/ 05 июня 2010

Я внимательно посмотрел на обе технологии в начале 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 также останется в обозримом будущем.

3 голосов
/ 04 июня 2010

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

2 голосов
/ 04 июня 2010

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...