Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

scrottie (4167)

scrottie
  scott@slowass.net
http://slowass.net/

My email address is scott@slowass.net. Spam me harder! *moan*

Journal of scrottie (4167)

Friday January 15, 2010
10:01 AM

Less non-constructive thoughts on DBIx::Class

[ #40105 ]

Working with the Web, there's going to be some kind of a dispatch or system for getting requests to handlers and there is going to be the handlers. Then with a database there is logic to fetch from and store to the database. You've probably just stepped into a trap. In a useful object design, objects are named after the nouns the system was written to operate on, and after the verbs it performs on those objects. The program is a reflection of the problem it's meant to solve and enough of the problem's world. If you're writing an accounting system, you would, ideally, have objects for lineitems, accounts, etc, and if you're doing a visitor type thing, then for actions that can be done on other objects. But, chances are, that's not what you're doing. Your problem has shifted from accounting to that of dealing with the computer you're programming. Your objects are named after this problem space instead: request handlers; the database; and so on.

MVC won't save you from defaulting to dumping business logic into big classes because OO-ifying the business logic isn't as pressing as setting up the web side and database glue.

You could subclass your DBIx::Class resultset objects and trust your schema to model the actual problem. That could work nicely if your database is full of useful views and uses views to abstract away the changing, growing actual schema. Or you could make a dedicated effort at putting objects in front of record set objects for important things ("account", "customer", etc) and letting those serialize/deserialize themselves using DBIx::Class with a has-a sort of relationship to the recordset objects they correspond to. There are other things you could use instead of DBIx::Class if you only want persistence -- KiokuDB comes to mind.

I don't have any brilliant thoughts right now other than to say, don't do that.

-scott

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.