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

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

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

Да ладно...

Что вообще говорить про LINQ2SQL? Он давно умер.

ViPRosКод должен может быть сгенерирован динамически.Поправил.

МСУПереходим все на Випрос Только внедряя инновации на раннем этапе проектирования можно добиться успешных стартапов в области IT-индустрии...

О чём это я...

(осторожно огляделся по сторонам, вышел из комнаты)

ViPRosне получится, даже демки сцуки не дают выставитьЭто хорошо или плохо?

А вообще да, внушительно: внедрения , проекты .

SolYUtorАлексей КТут всё зависит от конкретной ситуации. Если надо делать DTO - значит надо его делать. В EF есть выбор - делать или не делать. В NH выбора нет...
Очень даже есть. Приходилось видеть реализованный с доступом через хибер примерно ваш вариант, аля типизированные DataTable, включая таблицы связей m:m.
Только вот лажа это по сути. И самое главное, чем занимались при разработке EF4 - пытались его дотянуть до NHibernate в вопросе поддержки богатых доменных моделей. И им это более менее удалось. Но не все пользуются. :)С Ваших слов мне показалось что нет. С NH плотно не работал. Сори если что напутал. :-)

SolYUtorМСУ А о том, что не критерия "хорошеватости" системы.
Ваши сведения устарели лет на тридцать. Критерии давно есть.Как-то ко мне ходили консультироваться люди, работающие над универсальной формулой расчёта стоимости разработки ПО в зависимости от используемых средств разработки, количества разработчиков и т. п. Разумеется, затея кончилась ничем.

В этой статье описаны похожие труды...