Old NickПри таких требованиях ORM самоубийство
Глупости. 100500 раз уже обсуждали, что не в ORM проблема, а в кривых запросах, которые можно писать и без ORM. При грамотном использовании ORM никаких проблем не возникает.

P.S. Автор, используй Entity Framework.

mad_nazgulВсе ORM которые я видел, в т.ч. и от MS были таким убожеством, работая с ними я чувствовал связанным себя по рукам и ногам.
Не нужно какие-то феерические ограничения сопоставлять с убожеством ORM, можно сказать проще - ниасилил. В нормальных ORM всегда есть возможность использовать хранимые процедуры и кастом сиквел код, который типизированно намаплен на контекст. 90% рутинного кода выполняются через классический язык ORM движка, остальные 10% замороченного сиквела решаются через динамику с последующей типизацией. Баян, изъеженный годами.

mad_nazgulЯ понимаю, что программистам, которые не знают SQL они могут показаться проще, но у SQL гораздо гибче и богаче любого ORM.
Программист, хорошо разбирающийся в ORM, вовсе не означает, что он не разбирается в SQL. Это заблуждение тех же "специалистов", которые так и не осилили ORM и не поняли его сути и предназначения.

mad_nazgulХранимки можно использовать и без ORM ;-)
Зачем использовать лишнюю сущность, когда ее можно не использовать?!
Слово - типизация. Если не о чём не говорит, дальнейший разговор бесмысленнен.
Начни читать отсюда, возможно, не так всё плохо и прозреешь: http://msdn.microsoft.com/en-us/data/gg699321.aspx

mad_nazgulЛегкие вещи легко делаются и без ORM, а сложные в ORM не сделаешь.
См. выше.

mad_nazgulORM не поддерживает полностью стандарт SQL, соответственно он просто физически не может использовать все возможности SQL.
Зачем ограничивать себя, когда можно этого не делать?
ORM поддерживает любой стандарт SQL в разрезе используемого провайдера БД. Всегда есть выход на нативный DbCommand и DbConnection. Более того, всё это чисто и аккуратно маппится на заранее подготовленные сущности. Вот тут у меня на сайте пример есть: http://codearticles.ru/articles/2147
Даже есть в программе 90% сложного сиквел кода, всё-равно нужно использовать ORM. ORM - это визитная карточка к любой БД. Но тебе пока не понять, я вижу из контекста, что опыта работы с ORM у тебя ноль.

mad_nazgulГоворит.
Возвращаемый RecordSet всегда имеет типизированные поля.
Нет вру, в Visual Basic по моему все ч/з Variant делалось.
Далеко не только всё упирается в поля. Есть еще отношения один-ко-многим, многие-ко-многим и так далее.

mad_nazgulНасчет ХП...
Для каждой БД, нужно будет писать свою ХП.
Т.о. вы жестко привязаны к конкретной БД. ;-)
Как правило, "усредненный" проект содержит до 10% кода, который не решается средствами ORM. Этот код будет привязан к конкретной СУБД. Если нужно отмасштабироваться в разрезе смены хранилища, нам нужно переписать всего-лишь сиквел 10% кода. Для этого очень удобно подходит паттерн репозиторий или датасервис. Тут писал: http://codearticles.ru/articles/2155
Так же существует слабосвязность в проекте: http://codearticles.ru/articles/2301
Через которую можно элементарно отстыковывать логику работу с хранилищем и достыковывать новую. Всё это на ура решается с помощью ORM.

mad_nazgulЭто подтверждает мои слова.
Легкие вещи делаются легко, сложные никак.
Ах да, у нас есть ХП!
Вот только для каждой БД нужно писать свои ХП.
Да еще помнить, знает ли наш ORM особенности вызова ХП в данной БД. ;-)
Во-первых, хп писать не обязательно, можно хранить свой версионный код в своих репозиториях. Посмотри на ту же аксапту, ни одной хранимке, вся логика на сервере приложений, что и правильно. Во-вторых, я написал выше, даже если и есть хранимые процедуры, их количество минимально. Учить ORM ничему не надо, нужно использовать просто другой провайдер для подключения к другой БД. Все вызовы нативны. Посмотри тот же NHibernate, сколько он поддерживает БД.

mad_nazgulORM - это не визитная карточка БД.
ORM - это всего лишь "синтаксический сахар".
Которым удобно пользоваться для несложных вещей. Ну например, вывести табличку в гриде, или создать формочку для редактирования. Для тех кто не знает SQL.
Им удобно пользовать для любых вещей, и сложных и легких. Нужно просто иметь прямые руки и понимать, как можно гибко всё оборачивать данным механизмом. Вся работа с БД должна вестись через ORM и его прокси классы, которые пробрасываются через IDataService. Никаких проблем. И байдинг к гриду тут вообще не причем, смотри на вещи более абстрактно, а не формочками.

mad_nazgulДля сложного отчета, ORM чтобы работать нужны ХП.
А нет, вы еще забыли про представления. ;-)
Когда все можно было бы сделать просто запросом.
Для чего в ORM нужен нативный DbCommand и DbConnection.
Вот как раз для таких случаев, когда ORM просто не хватает и писать нативный SQL.
Выше написал - храним честный код в своих датасервисах, для отчетов пусть будет SqlReportDataService: IReportDataService. Даже если сменится БД, мы переписываем только этот сервис поставки на OracleReportDataService: IReportDataService. И все отчеты у нас продолжают работать без переписывания их логики. Нужно вставить какой-то фейк или протестировать юниты или модульность - вообще без проблем, подсовываем свой тестовый IReportDataService и репорт начинает рендериться по другой логике. Это как конструктор.

mad_nazgulЯ был бы не против, если бы ORM полностью соответствовала SQL, но это не возможно даже теоретически.
Т.к. SQL ЯП более высокого уровня, чем ООП ЯП.
Соответственно ORM который будет 100% соответствовать SQL просто будет SQL.
Вообще работа с ORM мне чем то напоминает работу с xBase.
ORM полность соотвествует SQL текущего провайдера, ты просто не умеешь это готовить.