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 гавно. Фёрст тоже гавно. Всё гавно!Это не я предлагал стреляться. :-)