Здравствуйте, Danchik, Вы писали:

D>Давайте я лучше сразу напишу как будет выглядеть код. Классы автоматом сгенерятся T4 шаблоном или простым описанием.
D>

...
D>

Выглядит симпатично. В принципе, использование ORM в качестве легкого ETL — довольно интересная мысль.
Особенно, когда качаешь ни пойми откуда в понятно куда.
Далеко не всегда использование Информатики, BO DI, Талента или того же Пентахо — выглядит, как красивое архитектурное решение.
Надо подумать.

Здравствуйте, Titus, Вы писали:

T>Здравствуйте, Danchik, Вы писали:

D>>Давайте я лучше сразу напишу как будет выглядеть код. Классы автоматом сгенерятся T4 шаблоном или простым описанием.
D>>

T>...
D>>

T>Выглядит симпатично. В принципе, использование ORM в качестве легкого ETL — довольно интересная мысль.
T>Особенно, когда качаешь ни пойми откуда в понятно куда.
T>Далеко не всегда использование Информатики, BO DI, Талента или того же Пентахо — выглядит, как красивое архитектурное решение.
T>Надо подумать.

Когда мне говорят надо написать синхронизатор или архиватор базы, я сразу говорю, плевое дело, но только если я использую linq2db. Не трудно представить, что так же я генерирую тестовые данные чтобы проверить производительность запросов.
Чтобы осмыслить что вы пропускаете через взрослую ORM, просто гляньте на разницу в запросах https://github.com/linq2db/linq2db/pull/1278

S>Приличные ORM гораздо больше усилий вкладывают в то, что от них требуется (порождение качественного SQL для динамически скомпонованных запросов; декомпозиция запросов; минимизация трафика между апп- и дб-сервером, оптимизация скорости чтения/записи)

имя , сестра!

Здравствуйте, koenig, Вы писали:

S>>Приличные ORM гораздо больше усилий вкладывают в то, что от них требуется (порождение качественного SQL для динамически скомпонованных запросов; декомпозиция запросов; минимизация трафика между апп- и дб-сервером, оптимизация скорости чтения/записи)

K>имя , сестра!

Думаю я не ошибусь если отвечу за Антона, в его же манере намеков . Имя вот тут в топе по скорости https://github.com/StackExchange/Dapper#performance

Здравствуйте, Sinclair, Вы писали:

S>Нет, EF унылый отстой не потому, что он ORM, а потому, что он отстой.
А Spring Data?

Здравствуйте, koenig, Вы писали:

S>>Приличные ORM гораздо больше усилий вкладывают в то, что от них требуется (порождение качественного SQL для динамически скомпонованных запросов; декомпозиция запросов; минимизация трафика между апп- и дб-сервером, оптимизация скорости чтения/записи)

K>имя , сестра!
Как всегда — https://github.com/linq2db/linq2db

Здравствуйте, Rhino, Вы писали:

R>Здравствуйте, Sinclair, Вы писали:

S>>Нет, EF унылый отстой не потому, что он ORM, а потому, что он отстой.
R>А Spring Data?
Не смотрел.

Здравствуйте, Titus, Вы писали:


T>Не, ну понятно, если есть некая корпоративная культура писать кривые и медленные корпоративные решения, то да, вещь нужная. Рабочих мест нужно больше.
T>Маневров для оптимизации больше (после того, как черепаху в продакшн выпустили) и т.д. Если заказчик богат, то с него можно снять несколько урожаев за один и тот же продукт.

T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.

Начнем с того, что ОРМы бывают разные: тяжеловесные, генерирующие запросы и легковесные, в которых программист сам пишет запрос, а ОРМ выполняет только маппинг.
Тяжеловесные ОРМ мне самому не нравятся, как правило генерят ужасные запросы как на выборку, так и на модификацию. Тем же EF из коробки пользоваться без EF+ просто нельзя.
А так леговесные ОРМ предоставляют тебе удобный маппинг который тебе не нужно реализовывать самому.

Здравствуйте, white_znake, Вы писали:

_>А так леговесные ОРМ предоставляют тебе удобный маппинг который тебе не нужно реализовывать самому.

link2db к каком классу относится?

Здравствуйте, Titus, Вы писали:

T>Здравствуйте, Osaka, Вы писали:

O>>Корпоративная автоматизация нужна тогда, когда она нужна (вчера) и приемлемого качества, а не идеального качества когда уже не нужна
T>Если я правильно понял твою мысль: "С ORM разработка быстрее".
T>Это был бы шах и мат, если бы это было бы правдой.

T>На самом деле, конкретно в моей практике. Есть задача. Есть эстимация программистов, которая в четыре раза больше моих ожиданий.
T>На мой вопрос: "а вы не обнаглели ли?", — получил ответ: "Так ведь это же Wildfly Hibernate ORM! Здесь все серьезно! Это на коленке делать быстро, а у нас сервер приложений, все по-взрослому".
T>Прям хоть бери и под видеокамеру их сажай...

Если ORM мешает работать — нафик такое нужно. Hibernate еще та клоака. Набросали туда всемогуторов, она и повернуться нормально не может. Кеши настрой, модель надизайни, репозиториев нафигач. Воркараунды — все на голом сиквеле. Брр.
Мне давно не мешает и долетаю я к финишу первым.

Здравствуйте, Titus, Вы писали:

T>Здравствуйте, white_znake, Вы писали:

_>>А так леговесные ОРМ предоставляют тебе удобный маппинг который тебе не нужно реализовывать самому.

T>link2db к каком классу относится?

К наилегчайшим ))

Здравствуйте, Rhino, Вы писали:

S>>Нет, EF унылый отстой не потому, что он ORM, а потому, что он отстой.
R>А Spring Data?

Почитал. Попытка под одним зонтиком собрать nosql и реляционки. Звучит как бред.

Здравствуйте, Cyberax, Вы писали:

C>Я работал с MySQL достаточно много. Он заметно быстрее PSQL для многих целей

И во всех таких целях nosql еще быстрее.

Здравствуйте, Somescout, Вы писали:

S>С оптимизацией может сейчас и лучше, но когда видишь как тривиальная модификация запроса ускоряет его в разы (в то время как MSSQL выполняет одинаково быстро оба варианта) — желание использовать НедоSQL пропадает.

В постгри с оптимизацией тоже все не очень. Его прелесть в том что он стабилен и честно реализует все типичные фичи рсубд. Мускуль в этом отношении сильно хуже, риски его использования на реальных проектах намного выше.

Здравствуйте, Danchik, Вы писали:

_>>>А так леговесные ОРМ предоставляют тебе удобный маппинг который тебе не нужно реализовывать самому.
T>>link2db к каком классу относится?
D>К наилегчайшим ))

Но запросы генерит

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Rhino, Вы писали:

S>>>Нет, EF унылый отстой не потому, что он ORM, а потому, что он отстой.
R>>А Spring Data?

НС>Почитал. Попытка под одним зонтиком собрать nosql и реляционки. Звучит как бред.

Spring Data — не попытка Оно широко используется как часть спринга, очень удобная штука.

Здравствуйте, anton_t, Вы писали:

НС>>Почитал. Попытка под одним зонтиком собрать nosql и реляционки. Звучит как бред.
_>Spring Data — не попытка

И не ORM — c R проблема.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Danchik, Вы писали:

_>>>>А так леговесные ОРМ предоставляют тебе удобный маппинг который тебе не нужно реализовывать самому.
T>>>link2db к каком классу относится?
D>>К наилегчайшим ))

НС>Но запросы генерит

Можешь его использовать как простой маппер, а можешь как универсальный SQL построитель — он в этом хорош.
Для некоторых он востребован как Linq over WCF, если вам надо спрятать базу с плохим security, а гибкость запросов необходима.

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Spring Data — не попытка
НС>И не ORM — c R проблема.
Не ORM. Но сколько там сахара!
Код не пишется, а генерируется. Запросы летают и всё такое (наверное).

Как раз то, за что ТС ратовал?

Здравствуйте, Rhino, Вы писали:

_>>>Spring Data — не попытка
НС>>И не ORM — c R проблема.
R>Не ORM. Но сколько там сахара!

А он нужен, сахар для key-value storage?