NHibernate против LINQ to SQL

Question

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

Answer 1

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

Проблема с шаблоном таблица-на-класс заключается в том, что структура вашей базы данных напрямую влияет на дизайн вашего домена. Например, предположим, у вас есть таблица «Клиенты» со следующими столбцами для хранения информации об основном адресе клиента:

• StreetAddress
• Город
• Состояние
• Zip

Теперь предположим, что вы хотите добавить столбцы для почтового адреса клиента, чтобы добавить следующие столбцы в таблицу «Клиенты»:

• MailingStreetAddress
• MailingCity
• MailingState
• MailingZip

Используя LINQ to SQL, объект Customer в вашем домене теперь будет иметь свойства для каждого из этих восьми столбцов. Но если бы вы следовали шаблону проектирования на основе домена, вы, вероятно, создали бы класс Address и в вашем классе Customer было бы два свойства Address, одно для почтового адреса и одно для их текущего адреса.

Это простой пример, но он демонстрирует, как шаблон таблицы на класс может привести к несколько вонючему домену. В конце концов, решать вам. Опять же, для простых приложений, которым просто необходимы базовые функции CRUD (создание, чтение, обновление, удаление), LINQ to SQL идеально подходит из-за простоты. Но лично мне нравится использовать NHibernate, потому что он способствует более чистому домену.

Редактировать: @lomaxx - Да, пример, который я использовал, был упрощен и мог быть оптимизирован для работы с LINQ to SQL. Я хотел сделать это как можно более простым, чтобы понять суть дела. Суть в том, что существует несколько сценариев, в которых наличие структуры базы данных, определяющей структуру домена, было бы плохой идеей или, по крайней мере, привело бы к неоптимальному дизайну ОО.

Answer 2

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

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

• Linq to NHibernate позволяет использовать Линк с Нибератом, так что может устранить причину не использовать.

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

---

Обновление

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

Работа Entity Frame с .net 4 также начинает выглядеть как реальная опция.

Answer 3

@ Кевин: Я думаю, что проблема с примером, который вы представляете, заключается в том, что вы используете плохой дизайн базы данных. Я бы подумал, что вы создадите таблицу клиентов и таблицу адресов и нормализует таблицы. Если вы сделаете это, вы можете определенно использовать Linq To SQL для сценария, который вы предлагаете. Скотт Гатри (Scott Guthrie) написал замечательную серию публикаций по использованию Linq To SQL , которые я настоятельно рекомендую вам проверить.

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

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

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

Многие люди называют LINQ To SQL как LINQ, но это не совсем правильно. Microsoft только что выпустила LINQ To Entities с .NET 3.5 SP1. Кроме того, NHibernate имеет интерфейс LINQ, поэтому вы можете использовать LINQ и NHibernate для доступа к вашим данным.

Answer 6

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

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

Answer 7

Сначала давайте разделим две разные вещи: Моделирование базы данных касается данных, а моделирование объектов - сущностей и отношений.

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

Преимущество NHibernate заключается в том, что он обеспечивает гибкость между моделированием вашего объекта и моделированием базы данных. База данных может быть смоделирована, чтобы наилучшим образом отражать ваши данные, например, с учетом производительности. В то время как моделирование вашего объекта будет лучше всего отражать элементы бизнес-правила с использованием такого подхода, как Domain-Driven-Design. (см. комментарий Кевина Пана)

В случае устаревших баз данных с плохими соглашениями о моделировании и / или именах Linq-to-SQL будет отражать эти нежелательные структуры и имена для ваших классов. Однако NHibernate может скрыть этот беспорядок с помощью картографов данных.

В новых проектах, где базы данных имеют хорошие имена и низкую сложность, Linq-to-SQL может быть хорошим выбором.

Однако вы можете использовать Fluent NHibernate с автоматическими сопоставлениями для этой же цели с отображением в соответствии с соглашением. В этом случае вам не нужно беспокоиться о каких-либо средствах отображения данных с XML или C # и позволить NHibernate генерировать схему базы данных из ваших сущностей на основе соглашения, которое вы можете настроить.

С другой стороны, кривая обучения Linq-to-SQL меньше, чем NHibernate.

Answer 8

Как вы написали "для человека, который не использовал ни один из них" LINQ to SQL прост в использовании, поэтому любой может легко его использовать Это также поддерживает процедуры, которые помогают большую часть времени. Предположим, вы хотите получить данные из более чем одной таблицы, затем написать процедуру и перетащить эту процедуру в конструктор, и она создаст все для вас, Предположим, что ваша процедура называется «CUSTOMER_ORDER_LINEITEM», которая извлекает записи из всех этих трех таблиц, а затем просто пишет

MyDataContext db = new MyDataContext();
List<CUSTOMER_ORDER_LINEITEMResult> records = db.CUSTOMER_ORDER_LINEITEM(pram1, param2 ...).ToList<CUSTOMER_ORDER_LINEITEMResult>();

Вы также можете использовать объект записей в цикле foreach, который не поддерживается NHibernate

Answer 9

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