SolYUtorОсновная проблема с LINQ в том, что он очень хорошо ложится на объекты, и далеко не всегда удачно удаётся его прикрутить к БД. Насколько я знаю, даже мелкомягкие реализации под под EF далеко не всё возможности LINQ реализлизует.В EF достаточно возможностей для комфортной работы с LINQ-to-SQL. Главное относится к этому не как к LINQ, а как к генератору SQL. :-)
SolYUtorNHibernate тоже не исключение. Left join к примеру не поддерживается. (которые в LINQ делается через DefaultIfEmpty())Другими словами LINQ в NHibernate пока нет. :-)
SolYUtorВ общем можете использовать, но иногда его возможностей будет не хватать.Если что-то не получается сделать через LINQ - можно добавить в БД View, и делать LINQ-запросы к нему.

SolYUtorАлексей КДругими словами LINQ в NHibernate пока нет. :-)
Если рассматривать с позиций всё или ничего, то тогда и в EF нет.По сравнению с NH он там есть. И его вполне достаточно. :-)
SolYUtorАлексей КЕсли что-то не получается сделать через LINQ - можно добавить в БД View, и делать LINQ-запросы к нему.
C NHibernate? Через вьюхи в бд? Окстить, Алексей! Столько возможностей для запросов в NH, чтобы возвращаться к старым недобрым вьюхам.Почему "недобрым"?
SolYUtorИ дело не только в том, что их тоже надо поддерживать в адекватном состоянииИх будет не много, меняться они будут редко. Да и механизмы их поддержки в актуальном состоянии всеми давно изучены и опробованы на практике.
SolYUtorДля эффективной работы с БД нельзя полагаться на дефлотное поведение маппера. Как правило, это вопросы когда и в каком объёме грузить данные. Вот в хибере для этого много возможностей.Никогда не ценил Lazy Load, если об этом. Тут можно легко обходиться без него.
SolYUtorНе так давно делал обзор, почему EF намного хуже чем NH. Может быть как-нибудь выложу.Выкладывайте.

SolYUtorЕсли рассматривать с позиций всё или ничего, то тогда и в EF нет.С позиции разумной достаточности.

МСУДля меня хибер пригоден только для мелких пооектов. Ибо отсутствие дизайнера и кодогенерации . T4 чё?

depend86я и не знал, что в nhibernate 3 есть собственный linq :)
в следующем проекте попробуюЕсли как пишут выше в нём нет left join - браться за него рановато.

SolYUtorМСУКодогенерация модели по БД - наше всё.
Для мёртвых данных годится. Для настоящей доменной модели нет.Как ни крути, доменная модель крутится вокруг структуры БД.

По БД сгененировать DAL (Data Access Layer) доменной модели можно без проблем. А вот сгенерировать по DAL ( особенно, изменять имеющуюся ) БД со всеми её особенностями - уже вряд ли.

Писать вручную тоже не вариант. Что-то из этих двух (DAL или БД) нужно генерировать. Выбор напрашивается сам собой - генерировать DAL по БД.

Алексей КВыбор напрашивается сам собой - генерировать DAL по БД.В случае с LINQ - это генерация DataContext-а для используемого LINQ-провайдера.

SolYUtor1. БД проектируется из расчёта оптимального сохранения объектов DDD.Или DDD проектируется из расчёта оптимального доступа к данным?
SolYUtor2. Безжизнная доменная модель , сгенерированная по БД мне нафиг не спллющилась.Зачастую БД ложится один в один на бизнес-объекты.
SolYUtor3. NHibernate и есть тот самый DAL. Зачем его генерировать?Речь идёт о прикладной части DAL.
SolYUtorА вот маппинги для DDD объектов генерируются легко.Собственно о том и речь.
SolYUtorСгенерировать БД по маппингам - раз плюнуть.Да ладно... И индексы тоже сгенерятся? И check constraint? И тд и тп?
SolYUtorПроблема лежит в другой стороне - управление изменениями БД. Сам хибер эту проблему может решить лишь частично (подозреваю, что EF тоже).Кому нужны полурешения? Нет решения этой проблемы, и не будет.
SolYUtorДля миграций существуют другие, более удобные инструменты.Способа два, и оба автоматизации не поддаются:
1. Изменять структуру данных "рукописными" DDL-скриптами
2. Давать пустую БД новой версии и конвертировать в неё данные. Конвертатор, естественно, тоже придётся писать вручную.
SolYUtorНо для целей тестирования возможностей хибера более чем достаточно.И для тестирования полурешения не нужны.

SolYUtor тут.

> Пакетное чтение (MulityQuery, Future)

При наличии LINQ не требуется

> Пакетная запись, настраиваемая в конфиге.

Это да. Жаль что этого нет.

> Пакетная ленивая загрузка коллекций, сокращающая проблему N +1

При наличии LINQ не требуется

> Сверхленивая загрузка коллекций (Order.OrderLines.Count приводит к select count(*) )

При наличии LINQ не требуется

> Возможность постраничной выборки и фильтрации коллекций.

При наличии LINQ не требуется

> Разнообразные способы выборки: HQL, ICriteria, QueryOver, LINQ, SQL(включая хранимые процедуры)

Опять же при наличии LINQ ничего больше не надо. Хранимые процедуры в EF вызываются тоже.

> и трансформации результатов с использованием IResultTransformer.

Полезно. Но и отсутствие не критично.

> Кеш второго уровня.

Накойхер (с) вообще при наличии LINQ эти кэши?

> Большое количество точек расширения, открывающих широкие возможности по модификации поведения

В EF тоже достаточно мест, позволяющих нарастить функциональность.

> Как следствие из предыдущего пункта, существующие большое большое количество расширяющих фреймворков. Примеры:
> NHibernate.Envers - аудит

Пишется за 5 минут

> NHibernate.Validator - думаю понятно :)

Пишется за 5 минут

> NHiberante.Search - Полнотекстовый поиск с использованием Lucene.Net

Пусть БД ищет.

> NHibernate.Shards - горизонтальное масштабирование приложений.

Распределённый кэш? Если да - нах не нужен.

> Rhino.Security - библиотека для разграничения прав доступа.

На пару с WCF пишется за 5 минут

> Разнообразные способы маппинга объектов на бд:
> xml
> аттрибуты
> маппинг кодом (2 отдельных фреймворка + встроенная поддержка)
> по классам
> по соглашениям.

Это есть. См EF 4.1 CodeFirst

> Более мощный язык объектных запросов (HQL vs Entity SQL), позволяющий выполнять объектные DML-команды без загрузки
> объектов в память.

Плотно не пользовался ESQL. Да и зачем он нужен при наличии LINQ? А то что LINQ гораздо лучше HQL, во всяком случае у меня, сомнений не вызывает.

> Встроенная поддержка для логгирования генерируемых sql-команд.

Это да. Но тут у каждой БД должен быть аналог MSSQL Profiler.

> Более 10 разнообразных id-генераторов, включая наиболее эффективные для ORM HiLo и guid.comb.

Не знаю что это. И не интересно.

> Возможность маппинга разнообразных пользовательских типов (шифрованные строки, локализованные свойства, запись Enum как строки, и многое другое)

Обходимся имеющимся.

> Поддержка readonly свойств.

Зачем это?

> Поддеркжа коллекций элементов (например IList<int>)

Есть.

> Поддержка маппинга словарей (Dictionary).

Есть.

> Сильное сообщество программистов.

Есть.

ЗЫ: При наличии LINQ отпадает необходимость в куче маленьких запросов, на борьбу с которыми направлены всякие ленивые загрузки и кэши в NH. EF в первую очередь ориентирован на LINQ. В нём это просто не надо. Тут совершенно другой подход к проектированию сервисов с логикой.

SolYUtor... позволяющий выполнять объектные DML-команды без загрузки объектов в память. Весь LINQ-to-SQL на этом построен.

SolYUtorАлексей КИли DDD проектируется из расчёта оптимального доступа к данным?Зачастую БД ложится один в один на бизнес-объекты.
Таблицы - это данные, просто данные. DDD классы - это объеты, обладающие не только состоянием, но и поведением. Поведение вы по БД как генерировать собираетесь?Само собой, речь идёт о генерации бизнес-объектов. В них как бы логики никакой нет. Логика в сервисах.

SolYUtorАлексей КДа ладно... И индексы тоже сгенерятся? И check constraint? И тд и тп?
Да, можно.Пример генерации индексов в студию. С указанием кластерности, филфактора и ещё десятка их параметров. И под конкретную СУБД в отдельности.

SolYUtorХотя CheckConstaint в стиле DDD - это лишняя, двойная работа. Вынос логики в БД, чего я советую всячески избегать. Бывают случаи.

SolYUtorАлексей КСпособа два, и оба автоматизации не поддаются:
1. Изменять структуру данных "рукописными" DDL-скриптами
2. Давать пустую БД новой версии и конвертировать в неё данные. Конвертатор, естественно, тоже придётся писать вручную.
Почти угадали. Для откройте для себя migrator.net и fluentmigrator . Да, всё равно скрипты пишутся ручками через fluent api. Зато рутину по их применению в правильном порядке берут на себя.Ну, а я что сказал? :-) А топологической сортировкой скриптов нас не удивиш.

SolYUtorВы правы. Это другой подход. В вашем случае это по сути замаскированные под объекты таблицы, т.к. ничего кроме данных в них нет .SRP в действии. :-)