Dropping Rails, but not its bad lingo

A ran across this article recently making the rounds. In it, the author discusses spending 2 years in Ruby on Rails land before finally giving up and coming home to PHP, wiser for the experience. It's a good article, but one thing in it really raised the hair on my neck.

Permit me to quote a few pertinent lines:

* all logic is coming from the models, one per database table, like Martin Fowler’s Active Record pattern.
...
* real MVC separation: controllers have no HTML or business-logic, and only use REST-approved HTTP. (GET is only get. Any destructive actions require POST.)

Excuse me while I bang my head against a table repeatedly.

When exactly did MVC turn into "dump everything into the model object and have no other code"? Why are you mixing the controller and the model? Oh wait, that's right, it's because you don't actually know what MVC means, because you've only listened to the RoR propaganda about it that is flat out wrong.

Really, the more I learn about and use Rails-style frameworks, the more I'm convinced they're a bad idea. They're what they say they are: A rail-game in which you have no flexibility or ability to define your own workflow. If you're building something more complex than a blog, it will get in your way. And it's still not MVC. It's a totally bastardized PAC.

Granted, some are better than others, and my primary experience has been with a particularly bad one. But I still hate any framework that mixes data objects and non-data-object business logic into a single object. And if you have to instantiate an object in order to get generic functionality that is not dependent on an instance of a piece of data, then you need to stop drinking the object koolaid. Making everything an object is blind bloat, just as skipping objects completely is blind stubbornness (or using PHP 4, which means you're already doing something wrong).

End Rant.

Comments

Which one?

Particularly bad one ... being which one? Just curious. If you don't wish to post publicly, would appreciate an email that I'll keep confidential.

UN Intervention

Perhaps the answer if for the IT staff at the UN send in a peacekeeping force to seperate the two camps and bring them to the table to negotiate a settlement.

Stateless object instances

And if you have to instantiate an object in order to get generic functionality that is not dependent on an instance of a piece of data, then you need to stop drinking the object koolaid.

I may be missing (or overlooking) some context for the above, but in languages such as PHP and Java, the only way to achieve polymorphism is to use object instances. Many times that is more than enough justification to create an instance of an object that has NO fields or state whatsoever. Polymorphism is necessary to implement things like the Strategy pattern, for example. Since languages such as PHP and Java lack closures/anonymous functions, it's really the only way to achieve that level of indirection, without resorting to hacks such as eval(), create_function(), call_user_function(), and so forth.

call_user_func()?

I will agree that eval and create_function() are nasty, but what's wrong with call_user_func() and friends? call_user_func() lets you do, effectively, function-level polymorphism. It's quite powerful and flexible. Exhibit A, Drupal, which uses it extensively to great effect. :-)

I'm not against OOP, mind you. Objects are a quite useful tool. But making everything an object just 'cause is needless complexity, and very often there are other perfectly viable ways to get the dynamic effects you want.