[OT] perl and CLRs

Steve Sims s.sims at fairfx.com
Wed May 9 10:14:45 BST 2007


On 7/5/07 15:35, "Matt S Trout" <dbix-class at trout.me.uk> wrote:
> Unless of course you mean "something that calls itself MVC but puts all
> the business logic in the so-called controller" or "something that calls
> itself an ORM but considers non-auto-inc single-column keys and any feature
> not provided my MySQL 4 'legacy'". They can keep those bits of rails, to
> my mind.

OK I'll bite.

This, sir, is FUD.

On your first point, it's up to individual programmers to ensure that
business logic gets put where it belongs.  I've seen Catalyst applications
(which calls itself MVC) where the business logic is in the so-called
controller...  It is trivial to place business logic in Rails 'Model'
components.  I would argue that this criticism is without merit.

Your understanding of ActiveRecord (assuming that is the ORM to which you
are referring) appears to be slightly lacking or outdated.  The *convention*
with ActiveRecord is to use an "id" column that auto-increments as the
primary key.  This is however configurable, and it is trivial to use a
different column; following the conventions of Rails simply means less
configuration work to do.

Composite keys are also supported through a Ruby Gem:
http://compositekeys.rubyforge.org/

I must admit I'm puzzled as to why the Rails folks are so keen on using
MySQL, having gladly rid myself of that abomination some time ago.  There
are of course drivers for Pg, SQLite, Oracle, etc.  I have seen nothing that
implies to me they're limiting themselves to MySQL 4.

In my day job I write DBIx::Class and Catalyst code.  I can see many ways in
which DBIx::Class could be improved having been learning ActiveRecord.
Migrations is a major concept in ActiveRecord that has no corollary in
DBIx::Class, for instance...

Steve



More information about the london.pm mailing list