Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I've been using Grails on a couple of projects over the past year and have found that the development productivity gains far outweigh the cons, and I haven't found a con that I couldn't work around. </p> <p>Regarding some of your specific objections:</p> <blockquote> <p>1) are implemented awfully. They don't seem to be able to extend from super classes at runtime. I tried this to add base actions and helper methods, and this seems to cause grails to blow up.</p> </blockquote> <p>FWIW, I've never felt the need to extend the controller from a base class. Each controller supports specific HTTP calls that don't lend themselves to reuse, and anything needed reuse can/should be delegated to a service.</p> <blockquote> <p>2) are based on an obsolete request parameters model (rather than form backing objects, which are much nicer).</p> </blockquote> <p>Again, FWIW this hasn't been an issue for me. Grails packages all the params nicely into a Map, which is all I usually need. If I need more, I create a Command object, which is pretty straightforward.</p> <blockquote> <p>3) are hard to test. Command objects are treated totally differently... and it's actually MUCH harder to write the test than it is to write the controller code.</p> </blockquote> <p>Yep- testing in grails is one of it's low points. I've abandoned Grails test harnesses completely and just use Selenium to automate testing via the GUI. Not ideal, but it's worked fine for us.</p> <blockquote> <p>6) The scaffolding that is generated is pure crap. It doesn't generalize inserts and updates... and it actually copy/pastes a pile of code in two views: create.gsp and edit.gsp. The views themselves are gargantuan piles of doggie do-do. This is further compounded by the fact that it uses low-level parameters and not objects.</p> </blockquote> <p>I've actually found the scaffolding to be pretty helpful in getting started. It never makes it to production in it's native form (except occasionally for internal apps), but it saves a ton of time getting started developing basic building blocks of your app. Also, you can always create your own scaffolding templates if you don't like the provided ones.</p> <blockquote> <p>Integration tests are 30x slower than a Spring integration test. It is disgusting.</p> <p>Some mocking tests are so hard to write and aren't guaranteed to work when it's deployed, that I think it discourages fast, tdd test cycles.</p> </blockquote> <p>Again, yes- testing is not Grails strong suit.</p> <blockquote> <p>Most things seem to screw up grails while it's running, like adding a taglib, or anything really. The server restart problem wasn't solved at all.</p> </blockquote> <p>I haven't had any issues in this areas since 1.2 came out. It's the cleanest change-while-running environment I've worked with. Certainly there are some things that require a restart (e.g. mods to bootstrap), but for most stages of development it works great.</p> <blockquote> <p>I'm starting to think going with Spring/Hibernate/Java is the only way to go. While there is a pretty big cost at startup, I know it'll eventually smooth out.</p> </blockquote> <p>Not only at startup, but all through the development process. I'm guessing that the teams I'm working with are producing production-ready features at a rate of 3-5x as fast as we could have using "traditional" frameworks. It's certainly not for everyone and every project, and it is not perfect, but it can be a huge accelerator if you're project fits into Grails strengths. Add to that the fact that you can largely pick and choose how much Grails you want to use (vs. tapping into Spring/J2EE layers if you want), and I see it as a "have your cake and eat it too" option. My 2c.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload