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

Question

Я считаю, что могу сделать больше с NHibernate и даже с Castle, чем с Linq to Entities или linq to SQL.

Я сумасшедший?

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

Цитата Linq, конечно, хотя и вписывается в общий «способ» работы .NET

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

Answer 5

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

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

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

Answer 6

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