AWG Blogs

  • Coding without IF statements - Found below linked article that provides tips on how to avoid using IF statements, with one of the benefits being readability. The tips largely are based o...
    1 day ago
  • Microservices - A species would be a combination of roles [DCI?], instead of being characterized as an animal, which would not necessarily be the best description. At a ...
    2 weeks ago
  • CoR compared to Pipe and Filter - Java World implies the pipes-and-filters architectural style described by Parnas Software systems often employ the equivalent of pipes (e.g., email filter...
    7 months ago
  • Getting ADB Working for SPH-M840 - Had a SPH-M840 Galaxy Ring Virgin Mobile 3G Android version 4.1.2, attempting to install apps from Android Studio failed to detect device. Installed SAMSUN...
    1 year ago
  • How to check if I have write permissions to an Oracle table - SELECT CASE WHEN COUNT(*) > 0 THEN 'YES' ELSE 'NO' END AS PERMISSIONS FROM ( SELECT privilege FROM ( select * from dba_tab_privs where (grantee = 'MY_USE...
    1 year ago
  • Flyweight vs Singleton - Implementations seems to be virtually identical, differing only in style, where the flyweight object is created and held by associated objects (containers:...
    2 years ago
  • init-param vs context-param - see for background. Gist: context-param variables are global and accessible thro...
    2 years ago
  • rbenv vs RVM - RVM is responsible not only for changing Ruby versions, but for installing rubies and managing gemsets, as well. ...Along with rbenv [to manage ruby versi...
    2 years ago

Saturday, March 7, 2009

Thoughts on Ruby on Rails

Was doing some research on the pros and cons of ROR and came across this article. A snippet:

Rails is designed from the ground up to create dynamic Web sites that use a relational database backend. It adds key words to the Ruby programming language that make Web applications easier to configure. In addition, it's designed to automatically generate a complete, if somewhat crude, Web application from an existing database schema. The latter is both Ruby's greatest strength and its Achilles' heel. Rails makes assumptions about database schema naming conventions that, if followed, make generating a basic Web site a matter of executing single command. But to do this may require additional configurations or in some cases may not be possible at all. You're also likely to find that just about every database convention that Rails expects can be overridden, but the more overriding that is needed, the less productive the platform becomes.

I knew this instinctively long ago when I did research debating whether to use an existing content management system (CMS) or create one from scratch. At that time, I was visiting blogs where followers of the ROR cult would rave about ROR and attack anyone that pointed out its flaws. There was this one guy in particularly that kept pointing to the database, and noting that the database design is too restrictive. He argued in favor of his own CMS, RADICORE, from which I got the idea to incorporate XSLT into my new CMS.

My opinion is that ROR is too tightly coupled to the database. The database design dictates the application. In that sense, it's a two-tiered application. I know next to nothing about ROR, but I've got friends and associates who work with it for a living. But I can't for the life of me understand the attraction of a platform that doesn't have a robust middle layer! Is there any concept of business objects in ROR?

Another article was linked to from the above article which lays out the restrictions and implications of a rails application:

Conventions that relate to legacy schema integration with Oracle and Rails include the following:
Tables are named in using the plural form of the model they represent. For example, an "employee" model maps to an "employees" table.
All tables that contain data that will be updated contain a primary key called "id."
In the case of Oracle Database, this primary key is incremented using a sequence with a name based on the table it increments. A table named "employees" that contains an "id" will be incremented by a sequence named "employee_seq."

Apart from the unappealingness of the restictions of how one must name the tables, I find something else more disquieting. The unspoken assumption in the Rails architecture is that tables map to entities in the traditional sense, i.e. that they reflect entities that appear perhaps in the real world and directly against which the application will perform its actions.

This makes integration of rails with one of my CMS's impossible, since the tables in my "MyEntityDB" framework are really meta-tables.

Then there's all those files in the "layouts" folder. That's another unspoken assumption that the design will reside in files. That makes another one of my CMS's impossible to work with Rails, because the design parts happen to reside in database table fields.

It also appears to be a cryptic version of Smarty.
Here's some sample ROR code from a downloadable app from here:

The embedded variables indicate a strong reliance on the application environment, which also I find disquieting. I prefer pure XSLT for the view layer, since it depends on XML for its data. That's what I use in my MyEntityDB framework, because it enforced complete separation between code and presentation (not just token separation as in Smarty Templates).

No comments:

Post a Comment