зыТак язык - это желаемое или необходимое?
Срорее, необходимое.
зыПочему не может быть ORM только для конкретной базы?
Отчего ж не может, может. L2S - для конкретного типа сервера (MSSQL), например.
зыДа пусть работает, я про заявление о строгой типизации базы
Ты ж спросил про "конкретность базы", а теперь говоришь о другом - о типизации. Определись. Типизация априори должна быть в ORM, исходя даже из самого названия - объектный маппинг.

зыок, тогда mybatis/ibatis, получается, тоже не ORM? Там нет собственного языка, транслируемого в XXX. Ну и наверное ещё каких-то свистелок, которые ты называешь необходимыми. Просто ты явно не ответил.
Согласен, что "неявно" ответил. И не отвечу, потому что нет однозначного определения ORM. Каждый продукт сам себя позиционирует.
Хибер позиционирует себя как ORM.
Telerik OpenAccess позиционирует себя как ORM.
BLToolkit позиционирует себя как ORM.
EF позиционирует себя как ORM.
...
Enterprise Library Data Access Block позиционирует себя как практику (хелпер, другими словами).

зыда что ты, я не спрашивал про "конкретность базы". Я вообще адресовал свой вопрос Lelouch , к тебе у меня были другие. Не люблю смешивать.
Ок, тогда сорри.

зы, по поводу JdbcTemplate: Доступ к данным в Spring

...Существует много статей о том, как делать инъекцию зависимости в Spring, но очень мало толковой информации о подключениях к базам данных. В Spring это можно делать либо напрямую при помощи JDBC либо использовать ORM технологии, например, Hibernate .

Согласись, очевиден четкий контраст: либо горбатый, либо не горбатый.

зыМСУ, я все к тому спрашивал, чтобы не вляпаться с тобой в очередную игру слов про ORM или не ORM.
Я это почувствовал изначально, поэтому старался "неявно" отвечать. Но когда вопрос стал ребром "горбатый или не горбатый" - я отписался про "самопроизвольную" трактовку вендора.

Но, так или иначе, мы привыкли к тому, что в ORM'ах есть
1. Готовые для работы классы (либо пишем руками, либо кодогенерируем с хранилища)
2. Язык общения с хранилищем (транслятор в SQL)
3. По возможности поддержка различных видов БД (нетрудно реализовать из п.2)
4. По возможности поддержка возможности создания новой БД из набора классов (в хибере делается одной строчкой SchemaExport.Execute())

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

[quot зы]такой тяжелый инструмент как ORM
В том-то и соль, что он не тяжелый. Он шустр и понятен, как березовый лист. Запросы выполняются там же на сервере, программист же общается с типизированными данными. Скорость та же. Микросекунды на маппинг объектов в коллекции не в счет. Тот же датасет дольше будет заполняться, чем наполнится коллекция того же хибера или EF.
Самое шустрое же - это IDataReader, но работать с ним так или иначе невозможно.

зыпочему любители compile-time проверок все время любят приводить в пример опечатки в строках? А если я опечатался и написал >= , или вместо нуля единицу?
Потому, что данный вид ошибки является самым распространенным. А от логической ошибки же (ошибки в бизнес-логике) ничего не спасёт, даже серебряная пуля.
зыУ тебя же все равно будут юниттесты, правильно? :) они и свалятся в случае ошибки.
Точно так же, можно ошибиться в юнит-тесте и написать 0 вместо 1. Так что мы ходим рекурсивно по кругу.

зыно все-таки давай рассматривать юнит-тесты как достаточный уровень защиты от подобных ошибок.
Ок. Но зачем доводить до последнего рубежа обороны, если можно на начальном этапе отсеять такую ошибку (ошибки именований или типов).
Далее - продуктивность и удобство работы (интелиссенс). Влияет ли на скорость и качество разработки? Или в помойное ведро его, этот подсказыватель? Думаю, тут всё очевидно.

зымаппинг - это результат работы всего, что ты написал выше. Именно что последнее, и базовое :)
Это результат, окончательный расчёт. Но, чтобы его сделать, нужно иметь полноценный движок, вот в нем вся и трудность.

[quot зы]Тяжелое и непредсказуемое начинается когда подключают, например, хибернейт. Если он избыточен для задачи, то достаточно jdbctemplate/mybatis для получения результата в виде POJO, с которым уже можно работать дальше используя парадигмы объектов.[/quot
Не понимаю, всё же. В чём тяжелость и избыточность хибера? Нужно переключиться на другую БД (например, Oracle) - переключаем провайдер в конфиге. Нужно развернуть базу по схеме в инсталляторе - вызываем метод, который по схеме все сделает.

Но так или иначе, самое ценное в ORM - это типизация хранилища, как следствие родной человеческий интелиссенс, с которым одно удовольствие работать. Рутинные же SELECT FROM WHERE в прошлом.

зыТут нет серебряной пули, так что спор — нужен ORM или нет без конкретной задачи сводится к простому мерянью пиписьками вида "а у меня проект больше и без ORM мы бы его делали в 10 раз дольше".
Нужен. Тысячу раз нужен, зы. Однозначно нужен, даже если база постоянна и прочие фантики не интересны.