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

Question

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

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

Answer 1

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

Но пусть это не отпугивает вас от linq.Linq все еще довольно хорошая идея..Попробуйте Linq to nHibernate :-)

Answer 2

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

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

Answer 3

Я использовал как 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 4

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

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

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

Answer 5

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

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

Answer 6

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