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 в действии. :-)

SolYUtorпродолжим дискуссию? Лехко. :-)
SolYUtorАлексей КSRP в действии. :-)
SRP в DDD не страдает.Страдания SRP зависят от нашего взгляда на предметную область. В данном случае мы выделяем хранение данных как отдельную ответственность. В случае с NH это не является ответственностью. Мне кажется это плохо. Но это моё мнение. Практика показала, что подход, применяемый в NH, тоже имеет право на жизнь.
SolYUtorДело в насилии над самым святым - инкапсуляцией.Несовсем. Сервисы могут быть инкапсулированы ( инжектированы DI-контейнером? ) друг в друга. Так же в сервис могут быть инкапсулированы кэшированные данные. Так что инкапсуляция тут применяется, и ещё как.
SolYUtorЕсли данные - чисто данные, то кто угодно может залезть к классу в трусы, оторвать достоинство, и прилепить свисток.Будет весело, но несколько неприятно.Это скорее хорошо чем плохо. Данные не зависят от способа их получения и обработки. Одни и те же данные могут обрабатываться разными способами. Это прекрасно.
SolYUtorДа и по сути, в таком случае у вас получается процедурное программирование - данные понятно, и процедуры - это сервисы WCF.Да. Можно провести аналогию с хранимыми процедурами в БД. А некоторые способы аналогичны работе с вьюхами (view) в БД. Это просто чудесно. :-)

МСУАлексей Кпропущено...
T4 чё?
Курили?Я с NH не работаю. Но активно использую T4 для генерации WCF-посредников и датаконтекста для EF.

МСУКороче, хачу такой дизайнер в хибере, как у L2S/EF. Где?Дизайнер L2S/EF - г..но. Лучше кодогенерация.

ЗЫ: За всю свою историю MS не родила ни разу нормального дизайнера.

SolYUtorАлексей КДа. Можно провести аналогию с хранимыми процедурами в БД. А некоторые способы аналогичны работе с вьюхами (view) в БД. Это просто чудесно. :-)
А я вот так не считаю. Хороший ООП стиль более модулен, с бОльшими возможностями повторого использования.Это надо ещё доказать. :-)

Помимо всего прочего, этот подход хорошо ложится на архитектуру SQL-СУБД. В итоге производительность может оказаться на много порядков выше ( один запрос vs N-запросов ). И с повторным использованием тут всё нормально.

Алексей КПомимо всего прочего, этот подход хорошо ложится на архитектуру SQL-СУБД.Про WCF-сервисы тоже забывать нельзя.

SolYUtorАлексей КЭто надо ещё доказать. :-)
Господин Макконнелл приводил в качестве доказательства исследования, проведённые на эту тему в NASA.Надо цитаты, примеры, ссылки. А так я тоже могу напридумывать. :-)
Да и наверняка Господин Макконнелл ещё не научился пользоваться LINQtoSQL-провайдерами. Это дело новое, не освоенное... :-)
SolYUtorАлексей КПомимо всего прочего, этот подход хорошо ложится на архитектуру SQL-СУБД.
Вот-вот! Наши подходы корреным образом отличаются. Я бооольшой любитель и сторонник ООП, поэтому для меня дико видеть обнажённые данные.Это понятно. Дело привычки.
SolYUtorАлексей К В итоге производительность может оказаться на много порядков выше ( один запрос vs N-запросов ). И с повторным использованием тут всё нормально.
Зависимость производительности от количества запросов более чем очевидна. Именно поэтому в хибере есть множество вариантов для оптимизации загрузки и вставки данных.Всё равно что "создать проблему, потом её героически решать". В EF ничего этого не надо.

SolYUtorАлексей КПро WCF-сервисы тоже забывать нельзя.
А вот тут мы уже приходим к SRP. :) И не только. На своих границах приложение не объектно-ориентированные, хотя физически мы оперируем объектами. Поэтому пытаться толкать DDD-cущности через границы WCF-сервисов - самоубийство. Для этого должны быть отдельные DTO-объекты.О чём и речь. В "моём" случае все бизнес-объекты хранят только данные и легко могут использоваться в качестве DTO. Экономия на тупом набивании кода может быть очень существенной.

Надо смотреть на конкретные факты а не филосовствовать на тему "объектноориентированности".

МСУА вообще я не испытаваю проблем с родными MS дизайнерами. Бросил, сгенерилось и заюзал. В этом сила.Сами же писали, что проект маленький. А попробуйте запихать в дизайнер 50+ таблиц... А разбивать на несколько датаконтекстов нельзя - в одном запросе не могут присутствовать сущности из разных контекстов.

Да и обновление маппинга при изменении структуры БД происходит раком.

Нуегонах...

МСУАлексей КСтреляйтесь сразу. Не Откладывая.
Нафига, если меня устраивает Дизайнер L2S/EF?
P.S. LLBLGEN гавно. Фёрст тоже гавно. Всё гавно!Это не я предлагал стреляться. :-)

SolYUtorАлексей КВсё равно что "создать проблему, потом её героически решать". В EF ничего этого не надо.
Надо Сеня, надо! Простой пример есть у нас заказ, заголовок и строки. И мы хотим его поредактировать. Так вот хоть чистый ADO.NET, хоть EF, хоть NH - один фиг надо загрузить данные из двух таблиц. Вопрос в том, с помощью какого API мы это сделаем.
В хибере для этого надо 1-3 строки в зависимости от используемого API. Это героические усилия?Я тут про всякие ленивые загрузки и кэширования, используемые внутри NH. В EF это тоже в каком-то виде есть, но масштабы не те. :-)
SolYUtorАлексей КВ "моём" случае все бизнес-объекты хранят только данные и легко могут использоваться в качестве DTO. Экономия на тупом набивании кода может быть очень существенной.
О! Вот как раз сейчас отказываемся от такой схемы. Ибо надо менять внутреннюю структуру, а на эти бизнес-DTO завязаны куча клиентов, интерфейс доступа для которых в общем-то не меняется, и меняться не должен.
Так что экономия на нескольких строчках кода выливается в дикий мазохизм над DTO. Эдакая прямая связность БД-Сервис-Клиент.Тут всё зависит от конкретной ситуации. Если надо делать DTO - значит надо его делать. В EF есть выбор - делать или не делать. В NH выбора нет...

МСУАлексей Кпропущено...
Сами же писали, что проект маленький. А попробуйте запихать в дизайнер 50+ таблиц... А разбивать на несколько датаконтекстов нельзя - в одном запросе не могут присутствовать сущности из разных контекстов.
Да и обновление маппинга при изменении структуры БД происходит раком.
Нуегонах...
Стоп стоп стоп. Про маленький проект - это хибер, причем тут линк? Во-вторых, у меня в контексте прекрасно живут порядка 200 таблиц и вьюх, плюс еще функции и хп.В ужасе пытаюсь представить диаграмму из 200+ таблиц...
МСУВ-третьих, если нужно закурить сущность из другой БД, берем руки, а в руки хп или функцию и делов? А так, для каждой БД - свой контекст.Да.
МСУВсё отлично.Сомневаюсь.
МСУПо поводу изменения структуры, согласен. Но ничего не поделаешь, бай дизайн. Удалил и закинул заново, 5 секунд. Привык уже На любителя. :-)

МСУ... а гавнофёрст-таки гавно ) НЕТ!

Да ладно...