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).
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).