NHibernate против LINQ для SQL

StackOverflow https://stackoverflow.com/questions/26971

Вопрос

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

Это было полезно?

Решение

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

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

  • Уличный адрес
  • Город
  • Состояние
  • Застежка - молния

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

  • Почтовый адрес на улице
  • Почтовый город
  • Почтовое государство
  • Почтовый архив

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

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

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

Другие советы

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

  • LINQ to SQL не работает с Oracle или любой другой базой данных, кроме SQLServer. Однако сторонние компании предлагают лучшую поддержку Oracle, например дотКоннект Деварта, DbLinq, Скорость света в Mindscape и АЛинк.(У меня нет никакого личного опыта работы с ними)

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

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

Обновить

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

Тот Самый Работа с Фреймом объекта начиная с .net 4, он также начинает выглядеть как реальный вариант.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top