- GORM with hibernate/spring and jpa is much better than ActiveRecord
- No distribution problems; runs in many production ready containers
- Internationalization out of the box (not specifically ignored as DHH does)
- Transactions actually work, and they include save-points.
- Not only dynamic finders and counters, but dynamic listOrderBy
- No green threads (although this may be fixed in Ruby 2.0, around 2010?)
- Ability to use pessimistic locking out of the box
- Real-live prepared statements and .withCriteria method
- Production level test reporting with built in Mocking and Stubbing
- Search operations are based on Lucene (with a plugin)
One thing I thought I might be giving up was the endless list of valuable gems that make developing in Rails a real pleasure. But after re-reviewing the list of open source products from apache, java source, spring, hibernate, and even Sun (glassfish), I can't think of any gems that I will miss.
![[FSF Associate Member]](http://www.raincitysoftware.com/images/fsf-member.png){kind=small}
10 comments:
Rails may get some of it once it's running on the JVM (thanks to Sun) with enough stability for production....
It'll be able to leverage all of the existing Java libraries then.
Unrelated, Grails is probably a much easier environment for Java devs to switch to, for all the obvious reasons.
Great post!
As a user of both frameworks, do you think there are any reasons to choose Rails over Grails? And do you think Grails is "enterprise ready"?
/Lars
"GORM with hibernate/spring and jpa is much better than ActiveRecord"
What is it about GORM that you like as compared to ActiveRecord? Declaring your properties in the model instead of in the database? Class Table Inheritance?
willcode4beer: yes, and I considered JRuby, but Grails seemed to make more sense (at least to me)...
lars: yes, I think for small projects with a few tables are easier to develop in rails. Also, if you are developing REST services without a UI, rails 2.0 is up to the job right out of the box. I did have to create custom templates to do this in Grails.
paul: I think it feels more natural to design with respect to the domain objects/properties rather than from the table/column point of view. The flexibility to use inheritance in hibernate with a single table or mutilple tables is another advantage. The caching is better (multiple vendor support). Composite primary keys. But the credit for all of this should be given to hibernate, not GORM...
Until GORM, I was not excited about the configuration requirements of hibernate, either through XML or using ugly tags. GORM makes it easy to define attributes and constraints that translate into table and columns. An since hibernate creates/updates on the fly, the migration step can be eliminated.
@paul:
I think not declaring your properties on the domain objects is the worst idea ActiveRecord brings to Rails.
Your domain model has to be clear to you as you develop your app. The fact that you have to constantly infer what it is from your DB schema is quite ugly and painful. I think no amount of being DRY can justify that omission.
darryl and sourceoferrors,
Thanks for the clarification. If you like Hibernate, the Ruby DataMapper project should be one to keep an eye. It is a replacement for ActiveRecord where you define your properties in your models, rather than have the properties inferred from the columns of the table. If it doesn't already, I believe it is planned to support both single table inheritance as well as class table inheritance. I'm not sure what the planned support for caching is. I think post people are of the opinion that page or page fragment caching is the way to go, rather than caching at the persistence level, who knows, maybe someone will hook DM up to Memcache, if there is a real need for that.
It's not even at 0.3 yet, so it's still an alpha stage project, but it could turn out to be a valid alternative to people who don't like ActiveRecord.
One more reason would be oversimplicity in rails. Imagine you have to write childish stuff like this...
f.write(@params['picture_file'].read)
The same stuff in Grails:
MultipartHttpServletRequest multiRequest = (MultipartHttpServletRequest)request;
CommonsMultipartFile file = (CommonsMultipartFile)multiRequest.getFile("file");
BufferedReader bin = new BufferedReader(new InputStreamReader(file.getInputStream()));
String line = bin.readLine();
// print each line
while (line != null) {
println("line: " + line);
line = bin.readLine();
}
Obviously the java way is fairly superior, and I skipped including the xml for the spring bean.
Let those Rails bastards write less code... our way is better, because... THIS IS SPA.... i mean THIS IS GRAILS!!!!
The careful reader would recognize that this post contrasts Grails and Rails, not Ruby and Java.
vortex:
We're talking about Groovy not Java here. Groovy code for the same:
def f = request.getFile('myFile')
if(!f.empty) {
f.transferTo( new File('someotherloc') )
response.sendError(200,'Done');
}
Pretty simple I think (yes, this one is two extra lines but it checks if the file uploaded is not 0 bytes...
(btw, this is the LONG way... you can also do
def img = new Image()
img.properties = params
)
Like most rails commenters, you don't seem to have ever tried groovy or grails.
Thanks for the insight. I am currently considering whether to use grails or rails. Your post seems to be objective and not biased. Thanks :)
Post a Comment