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

A>Кстати, почему? Был неудачный опыт использования или есть другие причины?
Причин масса, вот только на вскидку
— код нужно не забывать генерить. Т.е. если у меня на сервере работает класс, обработанный кодогенератором, то мне нужно проходить этап кодогенерации. Просто подменить такой класс на сервере я не могу.
— ошибки кодогенератора глобальны — влияют на все фичи проекта. Вот автор разрабатывает слой работы с БД. И любая ошибка кодогенератора одновременно проявляется в любой фиче приложения.
— ошибки кодогенератора нельзя править на месте — вот мне генератор нагенерил такой код, а мне именно в этом месте нужен другой. Для этого мне надо править кодогенератор. В большинстве хорошо спроектированых фреймверков это решается. Всегда где-то можно переопределить метод, или заменить локально нужную функциональность. С кодогенератором такое сложнее.
— для отладки ошибок кодогенератора, нужно иметь под рукой нагенеренные исходники. А если вдруг генерировался сразу байткод, то отладка идёт лесом.

Раньше имело смысл использовать кодогенерацию, т.к. генеренный код выдаёт хорошую производительность, в сравнении, например, с рефлексией. Но рефлексия сейчас хорошо оптимизирована. К тому же генерация SQL кода вряд ли может являтся узким местом в производительности.
Ещё кодогенерация имеет смысл для создания некоторой черновой структуры, как например, Spring Roo. Но только в случае дальнейшего отказа от постоянной кодогенерации. Ни Spring Roo, ни Seam (не совсем кодогенаратор, но идеологически близок) не выстрелили и массово не используются. Именно по причинам указаным выше.

Ищите в гугле и на rsdn, вопрос этот уже много раз обсуждался.