|
|
|
igilfanov |
|
|||
Новичок Профиль Группа: Участник Сообщений: 30 Регистрация: 4.10.2011 Репутация: нет Всего: нет |
Как создать аналог 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?
|
|||
|
||||
Laen8 |
|
|||
Новичок Профиль Группа: Участник Сообщений: 5 Регистрация: 23.4.2012 Репутация: 1 Всего: 1 |
Попробую ответить на вопрос. 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 млн строк) вам понадобится человек, который очень хорошо знает хибернейт. А если Вы собираетесь биржевые или банковские операции обрабатывать, то, на мой взгляд, лучше все же использовать более низкоуровневые технологии. |
|||
|
||||
igilfanov |
|
||||
Новичок Профиль Группа: Участник Сообщений: 30 Регистрация: 4.10.2011 Репутация: нет Всего: нет |
был печальный опыт работы с ним, не подходит для 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-представления. |
||||
|
|||||
Laen8 |
|
|||
Новичок Профиль Группа: Участник Сообщений: 5 Регистрация: 23.4.2012 Репутация: 1 Всего: 1 |
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 в промышленном режиме). |
|||
|
||||
igilfanov |
|
||||||||
Новичок Профиль Группа: Участник Сообщений: 30 Регистрация: 4.10.2011 Репутация: нет Всего: нет |
нашел здесь 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% из всех форм проекта. |
||||||||
|
|||||||||
igilfanov |
|
|||
Новичок Профиль Группа: Участник Сообщений: 30 Регистрация: 4.10.2011 Репутация: нет Всего: нет |
получается кастомной обработкой DDL можно также создавать триггеры
|
|||
|
||||
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | Java: Groovy & Grails | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |