При выборе ORM LINQ к SQL или LINQ к Объектам лучше, чем NHibernate?

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

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

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

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

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

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

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

Быстрый NHibernate идет некоторым путем к созданию этого менее болезненного.

Linq, конечно, хотя согласуется с общим 'путем', которым работает.NET.

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

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

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