3 ms·

My biggest complaint with Grails is its reliance on GORM - You can do sql, but it doesn't make it easy and the whole framework is really geared towards the ORM

My biggest complaint with Grails is its reliance on GORM - You can do sql, but it doesn't make it easy and the whole framework is really geared towards the ORM functionality and the opinionated view of the database and naming conventions. I need to be able to integrate with legacy data sets, and need more control over the database in general. Grails works well if your database is just a simple store for your application data.

babs474 13y ago
That is my experience too, but I blame it on hibernate which GORM is just a dsl wrapper for. Its fine when it works, but expect inscrutable session flushing errors when you try and flex it too hard.
_JamesA_ 13y ago
You can easily peel away the layers all the way down to direct SQL, completely bypassing GORM and Hibernate, when necessary.
ebiester 13y ago
I've used it with legacy applications with good success. If you really want, you can completely ignore GORM. Leave the domain directory blank, use command objects for your DAOs and DTOs. You can add your validation straight to command objects. On top of that, you can write your own hibernate xml on which your domain objects depend. If you get too fancy, you'll lose some of your GORM syntactic sugar, but you do have options.
- netcraft 13y ago
  This is interesting - do you know of any examples out there of the structure you're talking about?
  - ebiester 13y ago
    I've personally used it in a few hairy situations, but I haven't had to in a long time. http://stackoverflow.com/questions/425294/sql-database-views-in-grails http://stackoverflow.com/questions/425294/sql-database-views... is how you would do direct SQL without GORM, which you would use if you wanted to avoid hibernate entirely. The rest is just command objects - http://grails.org/doc/latest/guide/theWebLayer.html#commandObjects http://grails.org/doc/latest/guide/theWebLayer.html#commandO... - and more importantly, @Validatable. http://grails.org/doc/latest/guide/validation.html#validationNonDomainAndCommandObjectClasses http://grails.org/doc/latest/guide/validation.html#validatio... (Technically, command objects are a specific function within the controller, but what we're really looking to do is leverage the validation framework.) It's extra work, but no less so than avoiding an ORM in any framework. But if you can do it in Hibernate, you probably don't need to bother with this most of the time. (When I had to do it, it was to interface with stored procedures.) http://grails.org/doc/latest/guide/hibernate.html http://grails.org/doc/latest/guide/hibernate.html is there if you want to bolt GORM on to legacy classes.
hatchoo 13y ago
We use Grails purely for the convenience of its Views, Controllers, and Services. For the backend, we use Java - backed REST-like services. It is trivial to remove the GORM/Hibernate dependencies from Grails. If you can use No-Sql databases that offer a REST API, all you will need is an additional dependency on Httplib so you can make the calls.
olavgg 13y ago
Use Groovy SQL, it is as easy as: Sql sql = new Sql(dataSource) List results = sql.rows('SELECT * FROM mytable WHERE type_id = :type_id', [type_id: id])

babs474 13y ago

That is my experience too, but I blame it on hibernate which GORM is just a dsl wrapper for. Its fine when it works, but expect inscrutable session flushing errors when you try and flex it too hard.

_JamesA_ 13y ago

You can easily peel away the layers all the way down to direct SQL, completely bypassing GORM and Hibernate, when necessary.

ebiester 13y ago

I've used it with legacy applications with good success. If you really want, you can completely ignore GORM. Leave the domain directory blank, use command objects for your DAOs and DTOs. You can add your validation straight to command objects. On top of that, you can write your own hibernate xml on which your domain objects depend. If you get too fancy, you'll lose some of your GORM syntactic sugar, but you do have options.

netcraft 13y ago
This is interesting - do you know of any examples out there of the structure you're talking about?
- ebiester 13y ago
  I've personally used it in a few hairy situations, but I haven't had to in a long time. http://stackoverflow.com/questions/425294/sql-database-views-in-grails http://stackoverflow.com/questions/425294/sql-database-views... is how you would do direct SQL without GORM, which you would use if you wanted to avoid hibernate entirely. The rest is just command objects - http://grails.org/doc/latest/guide/theWebLayer.html#commandObjects http://grails.org/doc/latest/guide/theWebLayer.html#commandO... - and more importantly, @Validatable. http://grails.org/doc/latest/guide/validation.html#validationNonDomainAndCommandObjectClasses http://grails.org/doc/latest/guide/validation.html#validatio... (Technically, command objects are a specific function within the controller, but what we're really looking to do is leverage the validation framework.) It's extra work, but no less so than avoiding an ORM in any framework. But if you can do it in Hibernate, you probably don't need to bother with this most of the time. (When I had to do it, it was to interface with stored procedures.) http://grails.org/doc/latest/guide/hibernate.html http://grails.org/doc/latest/guide/hibernate.html is there if you want to bolt GORM on to legacy classes.

hatchoo 13y ago

We use Grails purely for the convenience of its Views, Controllers, and Services. For the backend, we use Java - backed REST-like services. It is trivial to remove the GORM/Hibernate dependencies from Grails. If you can use No-Sql databases that offer a REST API, all you will need is an additional dependency on Httplib so you can make the calls.

olavgg 13y ago

Use Groovy SQL, it is as easy as: Sql sql = new Sql(dataSource) List results = sql.rows('SELECT * FROM mytable WHERE type_id = :type_id', [type_id: id])