Как человек, который не использовал ни одну из технологий в реальных проектах, интересно, знает ли кто-нибудь, как эти два дополняют друг друга и насколько их функциональные возможности перекрываются?NHibernate vs LINQ to SQL
LINQ to SQL заставляет использовать шаблон таблицы для каждого класса. Преимущества использования этого шаблона состоят в том, что его быстро и легко реализовать, и требуется очень мало усилий для того, чтобы ваш домен работал на основе существующей структуры базы данных. Для простых приложений это вполне приемлемо (и часто даже предпочтительнее), но для более сложных приложений разработчики часто предлагают использовать шаблон domain driven design (что облегчает NHibernate).
Проблема с шаблоном table-per-class заключается в том, что ваша структура базы данных оказывает прямое влияние на дизайн вашего домена. Например, предположим, что у вас есть таблица Customers со следующими столбцами провести первичную информацию об адресе клиента:
Теперь, давайте например, вы хотите добавить столбцы для почтового адреса клиента, чтобы добавить в таблицу Customers следующие столбцы:
Использование LINQ для SQL, объект клиента в домене теперь будет иметь свойства для каждого из этих восьми колонн. Но если вы будете следовать шаблону проектирования, управляемого доменом, вы, вероятно, создали класс Address, и у вашего класса Customer были бы два свойства Address, один для почтового адреса и один для их текущего адреса.
Это простой пример, но он демонстрирует, как шаблон table-per-class может привести к несколько вонючей области. В конце концов, это зависит от вас.Опять же, для простых приложений, которым просто нужны базовые функции CRUD (создание, чтение, обновление, удаление), LINQ to SQL идеален из-за простоты. Но лично мне нравится использовать NHibernate, потому что это облегчает более чистый домен.
Редактировать: @lomaxx - Да, пример, который я использовал, был упрощенным и мог быть оптимизирован для хорошо работать с LINQ to SQL. Я хотел держать его как можно более простым, чтобы довести дело до конца. Дело остается в том, что существует несколько сценариев, в которых ваша структура базы данных определяет вашу структуру домена, будет плохой идеей или, по крайней мере, приведет к субоптимальному проектированию OO.
Можете ли вы пояснить, что вы подразумеваете под «LINQ»?
LINQ не является технологией доступа к данным, это просто функция языка, которая поддерживает запросы как встроенную конструкцию. Он может запрашивать любую объектную модель, которая поддерживает определенные интерфейсы (например, IQueryable).
Многие ссылаются на LINQ To SQL как LINQ, но это совсем не так. Microsoft только что выпустила LINQ To Entities с .NET 3.5 SP1. Кроме того, NHibernate имеет интерфейс LINQ, поэтому вы можете использовать LINQ и NHibernate для получения ваших данных.
По LINQ, я предполагаю, что вы имеете в виду LINQ to SQL, потому что LINQ сам по себе не имеет связанной с ним базы данных «goings on». Это просто язык запросов, на котором есть синтаксический сахар на лодке, чтобы заставить его выглядеть SQL-иш.
В базовых базовых примерах NHibernate и LINQ to SQL, по-видимому, оба решения одной и той же проблемы. Как только вы получите пропуск, вы скоро поймете, что NHibernate поддерживает множество функций, которые позволяют создавать действительно богатые модели домена. Существует также проект LINQ to NHibernate, который позволяет использовать LINQ для запроса NHibernate так же, как и LINQ to SQL.
Или вы можете использовать проект Castle ActiveRecords. Я использовал это в течение короткого времени, чтобы развернуть новый код для старого проекта. Он использует NHibernate и работает на активной схеме записи (удивительно, учитывая свое имя, которое я знаю). Я не пробовал, но я предполагаю, что, как только вы его используете, если вы почувствуете необходимость сразу перейти на поддержку NHibernate, это не будет слишком большим для этого для части или всего вашего проекта.
@Kevin: Я думаю, что проблема с примером, который вы представляете, заключается в том, что вы используете плохой дизайн базы данных. Я бы подумал, что вы создадите таблицу клиентов и таблицу адресов и нормализовали таблицы. Если вы это сделаете, вы можете использовать Linq To SQL для сценария, который вы предлагаете. У Скотта Гатри есть great series of posts on using Linq To SQL, который я бы настоятельно предложил вам проверить.
Я не думаю, что вы могли бы сказать, что Linq и NHibernate дополняют друг друга, поскольку это подразумевает, что они могут использоваться вместе, и, хотя это возможно, вам гораздо лучше выбрать один и придерживаться его.
NHibernate позволяет вам гибко сопоставлять таблицы базы данных с объектами домена. Он также позволяет использовать HBL для запроса базы данных.
Linq к SQL также позволяет отображать ваши объекты домена в базе данных, однако он используется синтаксис запроса Linq для запроса к базе данных
Основное различие в том, что синтаксис запроса Linq является проверяется во время компиляции компилятор, чтобы гарантировать, что ваши запросы действительны.
Некоторые вещи, о которых нужно знать с помощью linq, это то, что он доступен только в .net 3.x и поддерживается только в VS2008. NHibernate доступен в версиях 2.0 и 3.x, а также VS2005.
Некоторые вещи, о которых следует знать в NHibernate, это то, что они не генерируют ваши объекты домена и не генерируют файлы сопоставления. Вам нужно сделать это вручную. Linq может
сделайте это автоматически для вас.
Две точки, которые были пропущены до сих пор:
LINQ к SQL не работает с Oracle или любой базе данных кроме SqlServer. Однако третьи стороны предлагают лучшую поддержку Oracle, например. devArt's dotConnect, DbLinq, Mindscape's LightSpeed и ALinq. (Я не имею никакого личного опыта с этим)
Linq to NHibernate позволяет использоваться Linq с Nhiberate, так что он может удалить причину не использовать.
Кроме того, новый fluent interface to Nhibernate, кажется, делает его менее болезненным для настройки отображения NHibernate в. (Удаление одной из болевых точек NHibernate)
Update
Linq к Nhiberate лучше в Nhiberate v3, который сейчас находится в alpha. Похоже, что Nhiberate v3 может отправиться в конце этого года.
Entity Frame Work с .net 4 также начинает выглядеть как реальный вариант.
Fluent NHibernate может генерировать ваши файлы сопоставления на основе простых соглашений. Нет написания XML и строго типизировано.
Я недавно работал над проектом, где нам нужно было перейти от Linq To SQL к NHibernate по соображениям производительности. Особенно способ материализации объектов L2S выглядит медленнее, чем NHibernate, и управление изменениями также довольно медленное. И может быть трудно отключить управление изменениями для определенных сценариев, где это не нужно.
Если вы собираетесь использовать объекты, отключенные от DataContext - например, в сценариях WCF - возможно, у вас возникли проблемы с подключением их к DataContext для обновления изменений. У меня не было никаких проблем с NHibernate.
Вещь, которую я пропущу из L2S, - это, в основном, генерация кода, которая поддерживает отношения, актуальные на обоих концах сущностей. Но я думаю, что есть некоторые инструменты для NHibernate, чтобы сделать это там тоже ...
Как вы писали «для человека, который не использовал ни одного из них» 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>();
вы можете использовать вы запись объект в цикле Еогеаспа а также, что не поддерживаются NHibernate
первых давайте разделять две разных вещей: моделирования базы данных обеспокоено данными при моделировании объекта обеспокоены сущностями и отношениями.
Преимущество Linq-to-SQL заключается в том, чтобы быстро генерировать классы из схемы базы данных, чтобы их можно было использовать в качестве активных объектов записи (см. Определение шаблона активной записи).
Преимущество NHibernate - обеспечить гибкость между вашим моделированием объектов и моделированием базы данных. База данных может быть смоделирована для наилучшего отражения ваших данных с учетом производительности, например. Хотя ваше моделирование объектов лучше всего отражает элементы бизнес-правила, используя такой подход, как Domain-Driven-Design. (см. комментарий Кевина Панга)
С устаревшими базами данных с плохой моделью и/или соглашениями об именах, тогда Linq-to-SQL отразит эти нежелательные структуры и имена для ваших классов. Однако NHibernate может скрыть этот беспорядок с помощью карт данных.
В проектах greenfield, где базы данных имеют хорошее именование и низкую сложность, Linq-to-SQL может быть хорошим выбором.
Однако вы можете использовать Fluent NHibernate с автосоединениями для этой же цели с отображением в качестве условного обозначения. В этом случае вы не беспокоитесь о каких-либо картах данных с XML или C# и позвольте NHibernate генерировать схему базы данных из ваших объектов на основе соглашения, которое вы можете настроить.
С другой стороны, кривая обучения Linq-to-SQL меньше, чем NHibernate.
Вы можете закодировать реализацию своего репозитория с помощью Linq To SQL, это очень удобно. – 2009-05-02 15:42:49
Я думаю, что это не ActiveRecord, даже сопоставленные классы инкапсулируют часть логики инфраструктуры. Шаблон ActiveRecord был бы, если бы вы могли иметь Customer.Save(). L2S реализует шаблон работы с классом DataContext, например Session в nHibernate, но NH имеет реальный подход POCO. – 2009-05-29 08:50:49
Черт, L2S не является активной записью anymeans ... Активная запись означает, что объект сам сохраняет всю базу данных, а L2S - это не случай. – 2009-11-15 16:50:54