Зачем мне нужен LINQ, если я использую подобные ORM NHibernate?

Question

Я читал этот ТАК вопрос, но все же мне не ясна одна конкретная вещь.

Если я использую NHibernate, зачем мне LINQ?

Вопрос в моей голове обострился, когда я узнал, что NHibernate также включает поддержку LINQ.

LINQ для NHibernate?

WTF!

Answer 1

LINQ - это язык query .Это позволяет вам выражать запросы так, чтобы это не было привязано к вашему уровню персистентности.

Возможно, вы думаете о LINQ 2 SQL ORM .

Использование LINQ в названии этих двух причин вызывает неприятные недоразумения, подобные вашему.

nHibernate, EF, LINQ2XML - все Поставщики LINQ - все они позволяют запрашивать источник данных, использующий синтаксис LINQ.

Answer 2

Ну, вам не нужен Linq, вы всегда можете обойтись без него, но вы, возможно, захотите.

Linq предоставляет способ выражения операций, которые ведут себя на наборах данных, к которым можно обращаться, и где мы можем затем выполнять другие операции на основе состояния этих данных. Он намеренно написан так, чтобы быть максимально независимым, независимо от того, являются ли эти данные коллекциями в памяти, XML, базой данных и т. Д. В конечном итоге он всегда работает с каким-то объектом в памяти, с некоторыми средствами преобразования между оперативной памятью и конечный источник, хотя некоторые привязки идут дальше, чем другие, в переносе некоторых операций на другой уровень. Например. вызов .Count() может закончиться просмотром свойства Count, прокруткой коллекции и ведением подсчета, отправкой запроса Count(*) в базу данных или, возможно, чем-то другим.

ORM обеспечивают способ отображения объектов в памяти, и строки базы данных отражают друг друга, причем изменения одного отражаются изменениями другого.

Это хорошо вписывается в "некоторые средства конвертации" выше. Следовательно, Linq2SQL, EF и Linq2NHibernate выполняют как роль ORM, так и роль поставщика Linq.

Учитывая, что Linq может работать с коллекциями, вам нужно быть довольно извращенным, чтобы создать ORM, который вообще не мог бы поддерживать Linq (вам пришлось бы проектировать свои коллекции так, чтобы не реализовывать IEnumerable<T> и, следовательно, не работать с foreach). Более непосредственная поддержка этого означает, что вы можете предложить лучшую поддержку. По крайней мере, это должно сделать для более эффективных запросов. Например, если ORM дал нам средство для получения объекта Users, отражающего все строки в таблице users, то мы всегда сможем сделать:

  int uID = (from u in Users where u.Username == "Alice" select u.ID).FirstOrDefault();

Без прямой поддержки Linq, если Users реализовать IQueryable<User>, тогда это будет:

SELECT * FROM Users

Далее:

while(dataReader.Read())
  yield return ConstructUser(dataReader);

Далее:

foreach(var user in Users)
  if(user.Username == "Alice")
    return user.ID;
return 0;

На самом деле, было бы немного хуже. При прямой поддержке SQL-запрос будет выглядеть так:

SELECT TOP 1 id FROM Users WHERE username = 'Alice'

Тогда C # становится эквивалентным

return dataReader.Read() ? dataReader.GetInt32(0) : 0;

Должно быть достаточно ясно, как большая встроенная поддержка Linq провайдера Linq должна привести к улучшению работы.

Linq - это языковая функция C # и VB.NET, которая также может использоваться любым языком .NET, но не всегда с тем же языковым синтаксисом. Таким образом, когда-либо разработчик .NET должен знать это, и каждый разработчик C # и VB.NET должен знать это особенно (или они не знают C # или VB.NET), и это группа NHibernate предназначена для использования, поэтому они может зависеть от того, что вам не нужно объяснять целую кучу операций, просто реализуя их способом Linq. Отсутствие поддержки в библиотеке .NET, представляющей запрашиваемые данные, в лучшем случае следует рассматривать как отсутствие полноты; весь смысл ORM состоит в том, чтобы манипулировать базой данных как можно ближе к операциям, не связанным с БД, на используемом языке программирования. В .NET это означает, что Linq поддерживает.

Answer 3

Прежде всего, LINQ не является ORM.Это DSL для запроса объектов независимо от источника, из которого он получен.

Поэтому вполне логично, что вы можете использовать LINQ и с Nhibernate

Полагаю, вы неправильно поняли LINQв SQL с простым LINQ .

Answer 4

Здравый смысл?

Существует разница между ORM, например NHibernate, и интегрированным способом компилятора для выражения запросов, который используется во многих других сценариях.

Или: использование LINQ (не LINQ to SQL и т. Д. - язык, о котором вы говорите, хотя я не уверен, что вы имели в виду то, что вы сказали) означает, что вам не нужно иметь дело со специальным синтаксисом запросов Nhibernate.

Или: Любой, кто НЕ использует LINQ - независимо от NHibernate или нет - де квалифицируется без хорошего объяснения.

Answer 5

Вам не нужно , нужно , но вы можете найти это полезным. Имейте в виду, что Linq, как уже говорили другие, не то же самое, что Linq для SQL. Там, где я работаю, мы пишем собственные SQL-запросы для извлечения данных, но для нас довольно распространено использование Linq для манипулирования этими данными для удовлетворения конкретных потребностей. Например, у вас может быть метод доступа к данным, который позволяет вам найти всех собак, принадлежащих Дэйву:

new DogOwnerDal().GetForOwner(id);

Если вас интересуют только Daschunds Дейва для одной конкретной потребности, и производительность не так уж и важна, вы можете использовать Linq, чтобы отфильтровать ответы для всех собак Дейва до конкретных данных, которые вам нужны:

new DogOwnerDal().GetForOwner(id).Where(d => d.Breed == DogBreeds.Daschund);

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

В вашем примере вы можете использовать NHibernate для извлечения данных, а затем использовать Linq для разбиения этих данных на множество отдельных подмножеств для некоторой формы обработки. Возможно, было бы дешевле получить данные один раз и использовать Linq для их разделения, вместо того, чтобы повторно запрашивать базу данных для различных комбинаций одних и тех же данных.