This post originated from an RSS feed registered with Ruby Buzz
by David Heinemeier Hansson.
Original Post: Ruby on Rails approximations in Java
Feed Title: Loud Thinking
Feed URL: http://feeds.feedburner.com/LoudThinking
Feed Description: All about the full-stack, web-framework Rails for Ruby and on putting it to good effect with Basecamp
Ruby on Rails is stirring up the waters in the Java world. Matt Raible, the man behind AppFuse (kickstarting J2EE development), has been "thinking about Rails ever since I wrote a post about it".
The thoughts must have lead to some frustration with his current environment, though. Here's his description of why doing a CRUD on a single database table would flunk any productivity test:
...if I did it right now in AppFuse's current state, it'd be a disaster... To CRUD a database table using AppFuse you have to create 11 new files and modify 5 existing files. 16 files. What a beotch, huh? If I made a video of this - it'd be 20 minutes long!
While this might make AppFuse look silly, it's really more of a symptom of the patterns we have in J2EE and how we're supposed to architect our apps. 3 tiers, test-driven, loosely-coupled and internationalized.
Compare this to the Rails approach:
class Post < ActiveRecord::Base
# All attributes are given accessors
# through column introspection
end
class WeblogController < ActionController::Base
# The controller now has actions for all
# CRUD operations and uses introspection
# to select the input fields and columns
scaffold :post
end
I'd be depressed too if my environment forced me to go through a 20 minute setup phase (and that's for an expert, I'm sure creating and updating 16 files could easily take longer for people less skilled than Matt).
Naturally, this has spawned interest in remedying the situation for Java. Enter Trails by Chris Nelson:
The Trails framework is a domain driven development framework inspired by others that have gone before it such as Rails and Naked Objects. Its goal is to make developing database-driven web applications in Java radically easier, faster, and more fun. The basic approach is to eliminate as many of the steps as we can.
While I laud the aspirations for easing the pain that is J2EE, I'd advice treating the disease rather than the symptoms. Which is of course while I keep stressing the use of Ruby on Rails instead of just Rails. Rails cannot happen in a language like Java. Approximations will try, though.
But if you're stuck with J2EE as a fear-driven technology choice made by higher powers, I most certainly recommend checking out Trails. Chris is picking thebestinfrastructure J2EE has to offer and will attempt to make it fit like Rails. That's a great starting point and a good vision. Best of luck!