On Sat, Apr 17, 2010 at 4:35 PM, Octavian Rasnita <orasn...@gmail.com> wrote: > Hi, > > From: "John Karr" <brain...@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. >
On the speed note, I have a harder time getting TT optimized than anything with DBIC. TT is almost always my bottleneck, and usually harder to cache. _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
