НахлобучВот интересно мне, во что это вам выйдет. POCO-классы, используемые в NH, засорять всякими EntityRef<T>'ами и прочей специфичной для LINQ 2 SQL бурдой... Для NHibernate уже вовсю пишут IQueryable, так что есть шанс, что отказываться от него не придется.
Опять я чего-то не понимаю. Кто мешает, используя LINQ, вынести маппинг в XML-файл? Кроме того, мне показалось, что и в NHibernate удобнее пользоваться атрибутами, а не файлами маппинга.
Или я не о том?

Dmitdd НахлобучВот интересно мне, во что это вам выйдет. POCO-классы, используемые в NH, засорять всякими EntityRef<T>'ами и прочей специфичной для LINQ 2 SQL бурдой... Для NHibernate уже вовсю пишут IQueryable, так что есть шанс, что отказываться от него не придется.
Опять я чего-то не понимаю. Кто мешает, используя LINQ, вынести маппинг в XML-файл? Кроме того, мне показалось, что и в NHibernate удобнее пользоваться атрибутами, а не файлами маппинга.
Или я не о том?
Нахлобуч, Вы соскочили с темы или не заметили? Интересно Ваше мнение.

Нахлобуч
Да, проглядел.
Вы действительно не о том. Сам по себе LINQ 2 SQL (да и тем более LINQ) -- это далеко на ORM, коим является NHibernate, и даже вместе с ADO.NET EF (или как там она нынче называется) до NH они не дотягивают. Посему имеет смысл использовать LINQ -- по вполне понятным причинам -- в качестве замены Criteria API и HQL. Подробней -- тут .
Ну это понятно. До ОРМ ему далеко.
А вот мое мнение про POCO, что основной принцип "классы должны быть как можно проще" - не означает, что они не должны засоряться атрибутами, а означает, что никакой бизнес-логики, только описание класса. Согласитесь, что неудобно дергаться постоянно между классом и файлом маппинга. И следующий проект, который буду делать с NHibernate, буду маппинг прописывать прямо в классе с помощью атрибутов. Хотя вот тут боюсь ошибиться и буду признателен, если вовремя отговорите.
А вот мои доводы в пользу LINQ:
1) придется менять работу, а я с ним не работал - минус при приеме
2) у меня на работе никто и не слышал про NHibernate, зато как появился LINQ, все стали говорить, какая крутая это и полезная вещь, а про хибернейт так и не хотят ничего слышать.
Видно, что оба довода имеют одни корни - продукт толкается Microsoft, а потому его ну никак не проигнорировать и ему обеспечено блестящее будущее.

Нахлобуч
Начнем с того, что вам вместе со сборкой с вашими теперь уже псевдо-POCO-классами придется тянуть сборку с определениями этих атрибутов. Во-вторых, отдельные файлы маппингов все же удобней -- не мешаются в одну кучу код и разметка. В-третьих, атрибутами не все можно описать. В-четвертых, я не знаю, как там обстоят дела с HQL-запросами. Их текст тоже в атрибуты запихивать?

Здесь прям разрекламировали здесь
и назвали xml файлы nasty. Мне и самому привычнее пользоваться отдельными файлами маппинга. Думал, что использование аттрибутов - это следующий шаг в прогрессе хибернэйта.
Нахлобуч
От Линка я и не отговариваю -- наоборот, он прекрасно сосуществует с NHibernate. Пользуйтесь наздоровье.
Посему имеет смысл использовать LINQ -- по вполне понятным причинам -- в качестве замены Criteria API и HQL

Можно маленький примерчик того, где есть смысл стыковать LINQ и NHibernate?
Что-то до меня не дойдет, зачем заменять?