Как создать аналог sql-представления в виде доменного класса (например для sql-запроса: SELECT b.id, b.title, a.first_name, a.last_name FROM book b JOIN autor a ON b.autor_id = a.id)  в Grails?

Попробую ответить на вопрос.

1) Если надо выполнить один запрос, цитирую SO http://stackoverflow.com/a/425345/1050783 (в реальном прокете я бы завернул это все в сервис и использовал Spring JDBC template)

2) Обычно можно создать по этому view доменный объект. Сам с этим не работал, но в интернетах пишут, что все хорошо, хотя вроде бы выполнять апдейты по этому View лучше не стоит; и иногда могут требоваться подстройки hibernate DDL (http://grails.1312388.n4.nabble.com/Database-Views-and-Grails-Domain-Objects-td1389019.html)

3) Если я правильно понимаю, это все же антипаттерн. 
Как я уже сказал, выполнять апдейты по view лучше не стоит, а если апдейты не нужны, то зачем вообще доменные объекты?

GORM хорошо работает со стандартными мэппингами, и с его помощью можно адекватно описать почти любую схему базы данных, в этом его сила.
Ключевой момент - Вы пишете на groovy (lazy-loading, cascading и кэширование позволяют делать это удобно), а про базу данных, если верить рекламе, "можно не думать" (это вранье - без view и всевозможных PL/SQL обойтись можно без проблем, но знать, как код транслируется на БД и как оно все работает, конечно, надо).
На практике в команде должен быть человек, который разбирается с Hibernate, и он отвечает за все доменные объекты, а остальные разработчики могут писать код контроллеров и, тем более, GSP без особых знаний (большой плюс в том, что они могут залезть в код доменного объекта/сервиса со сложным criteria-запросом и посмотреть, что прибзительно там происходит - им не надо ползти самим в базу или идти к DBA).

В случае разработки типовой информационной системы (до миллионов строк в базе данных), производительность и гибкость будут вполне достаточными.
Для построения доменной модели над legacy-схемой базы данных, или разработки крупной информационной системы (10-100 млн строк) вам понадобится человек, который очень хорошо знает хибернейт.
А если Вы собираетесь биржевые или банковские операции обрабатывать, то, на мой взгляд, лучше все же использовать более низкоуровневые технологии.

был печальный опыт работы с ним, не подходит для MySQL и PostgreSQL  - оочень медленно выполняются запросы. Невозможно работать с временными таблицами и временными sql-представлениями.



на основе данного класса выстраивать формы поиска, гриды, для этого необходимо извлекать из доменного класса наименования полей с типами и соотвественно выполнять select-запросы.

Допустим существует 2 класса Book и BookView.
На основе класса Book создаем формы редактирования и просмотра,  а на основе BookView гриды и соотвественно фильтр по форме.

Цель использовать один подход, либо выстраивать все с помощью ORM DSL или без него используя SQL http://groovy.329449.n5.nabble.com/Groovy-...-td5434094.html.

Что нравится в ORM DSL, это представление таблиц в виде классов, включая валидаторы, ограничения и других крутых возможностей. Но как доходит до сложных запросов с объединением 2 и более таблиц, тут проблемки. Причем до сих пор не могу найти решение создания  view доменных классов, все что я нашел это создание доменного класса на основе уже существующего sql-представления.

1) Про производительность JDBC Template не буду пытаться ничего советовать, хотя предполагаю, что, если попрофилировать и правильно настроить, никаких проблем не должно быть - казалось бы, достаточно распространенная технология.

2) Касательно гридов и форм. Если Вы строите одну систему, я бы сказал, что работать на таком уровне абстракции и тратить очень много усилий на scaffolding не стоит - какой бы вариант Вы не выбрали, его все же придется существенно кастомизировать (когда Вам надо нарисовать действительно красивые и удобные формы, все равно придется редактировать их руками; когда надо создать формы "какие-нибудь лишь бы были", обычно подойдет и дефолтный scaffolding; - однако такой подход работает при agile процессе, когда легко влиять на требования в процессе выполнения проекта).

3) В то же время, если в Вашей компании ведется несколько проектов, и, например, стандартная функциональность выносится в плагины, то сделать что-нибудь общее действительно придется (к слову, на эту тему есть интересная презентация шведской команды http://www.slideshare.net/gr8conf/grails-ee, там также есть ссылки на их плагины rich-domain и gsp-taglib).

4) Про доставание метаданных из базы, которое обсуждается по ссылке из Вашего поста, я ничего тоже не буду комментировать - это работоспособный вариант, на моем предыдущем месте работы успешно использовалась очень мощная и сложная система метамоделирования, однако я здесь, опять же, не самый компетентный человек.

5) Задачу с Book и BookView, я сам скорее всего решал бы на уровне кастомизации scaffolding, подходящим образом учитывающей связи между объектами, возможно, добавив дополнительные специфичные для описания представления метаданные в описание доменных классов (пока я решал более простые задачи - в основном кастомизировал представление отдельных элементов UI/embedded классов, однако никто не запрещает выполнять и более сложные действия как в шаблоне view, так и в шаблоне controller). Повторю свою мысль - если мы возлагаем на ORM взаимодействие с базой данных, то решение задач уровня представления не должно влиять на базу данных. Но, безусловно, из любого правила есть исключения.

7) Возвращаясь наконец к созданию доменного объекта по View - по ссылке на mailing list, которую я приводил в п.2 своего предыдущего ответа, как раз об этом, вроде бы, и говорится (необходимо просто задать кастомную обработку DDL, а все select'ы работают в штатном режиме; конечно же, надо отключить версионирование и выбрать, откуда брать ID)

8) Гораздо лучше меня Вам ответят в grails mailing list; я за ним слежу - редко вопрос остается неотвеченным в течение суток (как запасной вариант - stackoverflow; вообще именно достаточная активность сообщества и убедила меня некоторое время назад в пользу использования Grails в промышленном режиме).

нашел здесь http://www.slideshare.net/gr8conf/gorm-burt-beckwith2011, круто надо попробовать. Спасибо за идею с кастомной обработкой DDL.



Spring JDBC Template подходит для распространенных комерческих СУБД : MSSQL, Oracle.  Даже не пытайтесь подружить с MySQL или с PostgreSQL, они и так медленные СУБД, а если в связке с Spring JDBC Template - это адская смесь.



scaffolding подходит для многостраничного приложения, я строю одностраничное ajax-приложение с использованием JavaScript-фреймворка. Но можно использовать create-scaffold-controller. Формы формируются по системе метамоделирования, например таким способом извлекаю наименования полей и типы:


HTML-форма формируется браузером.



совершенно верно, но по опыту знаю, что они составляют максимум 15% из всех форм проекта.

получается кастомной обработкой DDL можно также создавать триггеры