Обьекты и ORM

Проект вроде бы поднимается на ноги и в связи с этим решил создать тему о работе с обьектами Источник мозгования тут.

Немного информации.
Когда-то давно уже было обсуждение подобной темы (а даже больше ), но на другом форуме (ссылка).
В принципе с тех времен мало, что изменилось и вполне реально использовать ORM для работы с базой данных и XML, чисто на вскидку фреймворки: hibernate, castor xml.

Сабж.
И тут у нас возникает одна проблема: будет ли отдача от самого ORM-подхода? Все ORM фреймворки довольно сильно замедляют работу, по сравнению с jdbc, возможно стоит просто сменить пул коннектов на другой (менее багованный) и радостно попивать чай? Я конечно понимаю, что ORM довольно сильно упрощает работу с базой и другими внешними данными, но это все же серверное приложение и оно должно оправдывать свой статус. Писать же свой ORM-фреймворк - [матерное_слово], а точнее изобретение велосипеда с квадратными колесами, т.к. существуют стабильные фреймворки (и с более богатым функционалом), которые серьезно поддерживаются.
Если уж на скорость наплевать (относительно, всегда можно сделать распределенный сервер), то можно и IoC использовать: spring, google guice, etc (которые как раз дают неплохую почву для распределенного сервера).

Таск лист:
1. Установить насколько медленее ORM подход по сравнению с JDBC
2. Проверить потребление ресурсов и скорость работы под критической нагрузкой (около миллиона-двух некеширующих коннектов?)
3. Определить удобность использования IoC-компонентов в нашем случае

P.S: если идти по пути "DAO - везде" - то можно рассмотреть AspectJ препроцессор и уже с помощью него генерировать довольно легковесный код под DAO, причем в независимости от того с чем идет работа: от базы данных до xml. Эдакий четвертый вариант