NHibernate по сравнению с LINQ к SQL

Две сути, которая была упущена до сих пор:

• LINQ к SQL не работает с Oracle или любой базой данных кроме SqlServer. Однако третьи стороны действительно предлагают лучшую поддержку Oracle, например, dotConnect devArt, DbLinq, LightSpeed Mindscape и ALinq. (У меня нет личного опыта с ними)

• , Linq к NHibernate позволяет, Вы использовали Linq с Nhiberate, таким образом, это может удалить причину не использовать.

Также новое быстрый интерфейс к Nhibernate, кажется, делает его менее болезненным для конфигурирования отображения Nhibernate’s. (Удаление одной из болевых точек Nhibernate)

Обновление

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

Основа Объекта с .net 4 также начинает быть похожей на реальную опцию.

@Kevin: Я думаю проблема с примером, который Вы представляете, то, что Вы используете плохое проектирование баз данных. Я думал бы, что Вы составите потребительскую таблицу и таблицу адреса и нормализовали таблицы. Если Вы делаете это, можно определенно использовать Linq Для SQL для сценария, который Вы предлагаете. Scott Guthrie имеет большой ряд сообщений при использовании Linq К SQL, который я настоятельно рекомендовал бы, чтобы Вы проверили.

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

NHibernate позволяет Вам отображать свои таблицы базы данных на Ваши объекты области очень гибким способом. Это также позволяет Вам использовать HBL для запросов базы данных.

Linq к SQL также позволяет Вам отображать свои объекты области на базу данных однако, это использует синтаксис запроса Linq для запросов базы данных

, основное различие здесь - то, что синтаксис запроса Linq проверен во время компиляции компилятором, чтобы гарантировать, что запросы допустимы.

Некоторые вещи знать с linq состоят в том, что это только доступно в .net 3.x и только поддерживается в VS2008. NHibernate доступен в 2,0 и 3.x, а также VS2005.

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

Можно ли разъяснить то, что Вы подразумеваете под "LINQ"?

LINQ не является технологией доступа к данным, это - просто функция языка, которая поддерживает запросы как собственную конструкцию. Это может запросить любую объектную модель, которая поддерживает определенные интерфейсы (например, IQueryable).

Многие люди обращаются к LINQ К SQL как LINQ, но это нисколько не корректно. Microsoft только что выпустила LINQ К Объектам с.NET 3,5 SP1. Кроме того, NHibernate имеет интерфейс LINQ, таким образом, Вы могли использовать LINQ и NHibernate для достигания данных.

LINQ я предполагаю, что Вы значите LINQ для SQL, потому что LINQ, отдельно, не имеет никакой базы данных "продолжения" связанного с ним. Это - просто язык запросов, который имеет полную лодку syntac сахар, чтобы заставить его посмотреть выход SQL.

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

Или Вы могли использовать проект замка ActiveRecords. Я использовал это в течение короткого времени к подъему некоторый новый код для проекта прежней версии. Это использует NHibernate и работы над активным рекордным шаблоном (удивляющий данный его имя, которое я знаю). Я не попробовал, но я предполагаю, что, как только Вы использовали его, если бы Вы чувствуете потребность спасть до поддержки NHibernate непосредственно, это не было бы слишком много, чтобы сделать так для части или всего Вашего проекта.

Fluent NHibernate может генерировать файлы сопоставления на основе простых соглашений. Нет написания XML и строго типизировано.

Недавно я работал над проектом, где нам нужно было перейти с Linq на SQL на NHibernate по соображениям производительности. Особенно способ материализации объектов в L2S кажется медленнее, чем в NHibernate, а управление изменениями также довольно медленное. И может быть трудно отключить управление изменениями для определенных сценариев, где это не нужно.

Если вы собираетесь использовать свои объекты, отключенные от DataContext - например, в сценариях WCF - у вас может быть много проблема с подключением их к DataContext снова для обновления изменений. У меня не было проблем с этим в NHibernate.

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