Ruby is a wonderful language, but a language in and of itself is not a solution. There needs to be well designed frameworks provided so that developers have a model to work from and extend. I had learned about the Model-View-Controller paradigm during my Smalltalk period, but noticed that even the adherents to the idea often violated the principles, adding business logic in a view object and so forth. Enterprise Java developers had a fairly clear model with the Enterprise Java Bean, but the using of servlets as controllers and Java Server Pages as views wasn’t backed up by a proper set of tools to keep things straight. I saw a lot of business logic embedded in servlets, and even in JSPs. When working on MS-Windows projects, developers routinely stuffed monolithic blocks of code into Window procedures, making some of the ugliest, hardest-to-manage code ever written. The lesson here is that MVC is a great idea, but requires a well-thought-out framework that supports and enforces separation of code and concerns within the framework. Ruby-on-Rails (RoR) is that framework.
Like the Programming Ruby book, I found Agile Web Development with Rails to be an outstanding text, full of good humor and good sense. The Rails framework is very elegant, a wonderful piece of design and implementation.
In my opinion, RoR is what Java J2EE could have been, if it hadn't been bloated by big corporations throwing their weight around in standards committees. There just doesn't seem to be a reality check there. Who really needs all that complexity? Too many features were added in order to achieve competitive advantage over another high-tech rival, and not the needs of the customer.
My colleague and I have built and deployed several RoR applications so far. Nothing terribly complicated, but complete 3-tier applications that accept input, store data into databases, support a wide variety of query and reporting operations, and look pretty good too. My admiration for Ruby-on-Rails increases with each project.
No comments:
Post a Comment