[Catalyst] Alternatives to DBIx?

[Octavian Rasnita]

Hi,

From: "John Karr" <brainbuz at brainbuz.org>
> Working in raw DBI is the opposite of the DRY principle which underlies having a framework in the first place, so I am seeking an alternative. 
> Just as Catalyst uses MVC, DBIx chooses ORM, but that paradigm is not the only way to be effective PERL<==>SQL glue. From the 
> Manpage Fey::SQL looks like what I want: neatly wrapped and sweetened SQL, without the repetition and overhead inherent in working from > DBI. I'm going to spend some time working with it and also with SQL::DB, when I have a more educated opinion I will share it. Both Fey and 
> SQLDB are a nativist approach to SQL (much like TT is to html), and I would argue that in keeping the PERL paradigm of many ways to 
> accomplish a task, the choice between a SQL-native DBI wrapper and an ORM wrapper should be up to the individual, the issue seems to be > finding a worthy SQL-native wrapper.


If the overhead/speed is the most important thing, then DBI is better than DBIC (by the way is DBIx::Class or DBIC, not just DBIx).

But in that case you probably shouldn't be interested in using Template-Toolkit nor Catalyst, because they also have their overhead, and the other higher level modules used for accessing the database have their overhead also and the best solution would be DBI.

> In my own analysis the Time and Effort to learn DBIx is greater than the Time wasted writing repetitious DBI code, the time I've already invested > on DBIx has shown that there is a better way than DBI, but for me it isn't DBIx.

Of course that an application that uses just mod_perl handlers and not very many objects, templates, form processors, ORMs... is faster than one that use them, and for someone who doesn't know the interface of those modules is also faster to develop because no aditional learning time is required, but that application will be much much harder to maintain on the long term.

If the long term development process is important, then with very few exceptions, the applications should not be optimized prematurely because there may be found other more elegant optimizations than manipulating SQL code directly.

Learning the interface of DBIC takes some time, but you shouldn't learn it again and again for each new project, so on the long term the development process will be much faster.

If what you don't like at all is the DBIC syntax, then yes, in that case you have a good reason for using something else, but a good idea would be to learn it a little and try to use it in order to see its benefits.

Octavian