При выборе ORM лучше ли LINQ to SQL или LINQ to Entities, чем NHibernate?

Нет, ты не сумасшедший. nHibernate - это полноценный OR Mapper, Linq to SQL и Linq to Entities не реализуют всего, что вы ожидаете от OR Mapper, и ориентированы на несколько иную группу разработчиков.

Но пусть это не сбивает вас с пути. Linq по-прежнему неплохая идея .. Попробуйте Linq в nHibernate :-)

Большим недостатком NHibernate, Castle и т. д. Является то, что они не совсем легкие (особенно NHibernate).

Linq to SQL хорош для облегченного ORM с ограниченным использованием.

Следует иметь в виду, что NHibernate может быть абсолютной свиньей для настройки - тем более, что он основан в основном на файлах конфигурации XML из-за его корней, как у исходного Hibernate.

Свободно владеет NHibernate делает это менее болезненным.

Linq, безусловно, вписывается в общий «способ» работы .NET.

Я использовал как NHibernate, так и LINQ to SQL. С моей точки зрения, это зависит от проекта, если мне что-то нужно быстро, я бы выбрал L2S, так просто создать отображение dbml и начать его использовать. Если я разрабатываю корпоративное решение более высокого уровня, я бы выбрал проверенную и надежную ORM - NHibernate, я считаю, что функции ведения журналов и транзакций просты в использовании.

У LINQ to SQL относительно короткая кривая обучения, у NHibernate гораздо более крутая кривая обучения.

LINQ to SQL поддерживает только SQL Server, поэтому, если у вас есть база данных Oracle, решение уже принято - NHibernate.

Я бы рекомендовал посмотреть на http://www.summerofnhibernate.com/ отличные скринкасты по изучению NHibernate.

Я не пробовал Entity Framework, но определенно рекомендую NHibernate вместо Linq to SQL; Самая большая причина, которую я могу назвать, - это просто контроль. Linq to SQL любит иметь гораздо больший контроль над всем, загружая объект и поддерживая все виды отслеживающей информации об объекте. Если вы сериализуете / десериализуете, информация отслеживания может быть потеряна, и могут произойти странные вещи при ее повторном сохранении. NHibernate работает больше как репозиторий - вы передаете ему любой объект, который хотите (конечно, вы настроили его для понимания), и он помещает его в базу данных, независимо от того, что вы с ним сделали.

Blockquote Linq certainly though fits in with the general 'way' in which .NET works

Ой, меня пугает такое настроение. RAD-компоненты, встроенные в .net, НЕ являются принципом работы dot net, это просто набор инструментов для создания прототипов. .NET позволяет нам создавать полные DDD-приложения с высоким уровнем сплоченности, разделения проблем и позволяет нам писать несвязанный код, несмотря на все попытки ms объединить вещи. Я категорически не согласен с тем, что .net любит быть связанными, инструменты certian любят быть связанными, я включу linq to sql в эту драку. linq to sql разрушает идею отдельной доменной модели. Я съеживаюсь при мысли об использовании схемы моей базы данных в качестве базовых объектов модели. Правильные инструменты ORM должны позволить нам сначала смоделировать наш домен, а затем связать нашу реляционную базу данных с этими моделями. А не наоборот.