NHibernate против LINQ до SQL

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

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

• StreetAddress
• Город
• Государство
• Zip

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

• MailingStreetAddress
• MailingCity
• MailingState
• MailingZip

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

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

Edit: @lomaxx-Да, пример, который я использовал, был упрощенным и мог быть оптимизирован для хорошей работы с LINQ по SQL. Я хотел сохранить его как можно более простым, чтобы довести до дома точку. Тем не менее, существует несколько сценариев, в которых использование структуры базы данных для определения структуры домена было бы плохой идеей или, по крайней мере, привело бы к неоптимальному дизайну OO.

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

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

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

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

Обновление

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

Работа фрейма сущности по состоянию на .net 4 также начинает выглядеть как реальный вариант.

@Kevin: я думаю, что проблема с примером, который вы представляете, заключается в том, что вы используете плохой дизайн базы данных. Я бы подумал, что вы создадите таблицу клиентов и таблицу адресов и нормализуете таблицы. Если вы сделаете это, вы можете определенно использовать Linq-SQL для сценария, который вы предлагаете. У Скотта Гатри есть отличная серия сообщений об использовании Linq - SQL , которые я настоятельно рекомендую вам проверить.

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

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

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

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

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

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

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

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

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

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

Не могли бы вы пояснить, что вы подразумеваете под "LINQ"?

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

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

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

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

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

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

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

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

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

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

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

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

Как вы написали "for a person who have not used either of the them" LINQ - 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