|Do you know where your variables are?|
DBIx::Class, make me droolby metaperl (Curate)
|on Aug 25, 2011 at 15:09 UTC||Need Help??|
Do Moose and DBIx::Class go together like bread and butter? I'm currently using Moose and DBIx::Simple but I have a sneaking feeling that DBIx::Class would be sheer nirvana in this situation.
OK, so I have a bunch of classes which all inherit a base class method to obtain new data:
Now, getnewsql is a lazy-built method. In the first level of derived classes, the following role is used by some classes to get new data:
Now, in a class which needs to refine the WHERE clause with another clause, we override this lazy builder as follows:
eewww, it's so stringyI wonder if there is some way to do this with methods? DBIx::Class uses data structures to build SQL via SQL::Abstract and so the lack of methods there makes me wonder if there is a way to extend the query data structures in an OO-fashion
make a view my friend?ORMesque has a different take on object-relational Perl - simply build database views for each thing you need. Why am I doing all this dynamic query extension in OO Perl anyway? An alterative approach would be to simply map my various program query requirements to database views.
I think it's interesting to explore how best to tread the line between programming languages and relational database engines. I suppose that using an ORM allows you to be more dynamic but I'm not sure.
recent threadsa recent thread shows resultset restriction but not extension. I'd be curious as to how to extend things with DBIx::Class... or your opinion on database views as an alternative approach.
living breathing codeI wrote DBIx::Cookbook to build up an executable comparison reference, so contributions there are welcome too.
The mantra of every experienced web application developer is the same: thou shalt separate business logic from display. Ironically, almost all template engines allow violation of this separation principle, which is the very impetus for HTML template engine development.
-- Terence Parr, "Enforcing Strict Model View Separation in Template Engines"