Class::Accessor and Class::DBI
Don't use those. They were fine for their era but vastly superior tools exist: s/Class::Accessor/Moose/ and s/Class::DBI/DBIx::Class/; # or Rose::DB.
The sort of encapsulation and extensibility you get with these tools is enormous. Encapsulating code in situations like monetary apps is tremendously valuable. You can write code that simply won't work if it's misused. Code with pluggable log points and business logic that becomes easy to test and manipulate with configuration instead of code hacks. It's still Perl so it's internally fungible but Moose makes it easy to design solid APIs around this idea.
If you're serious about code quality and not being paged at 3am (or getting your company sued out of existence since money is involved) I recommend test driven design/development. It's not a fail-safe but it will save you huge amounts of time on the initial investment and allow you to write code boldly and quickly because you'll have the baseline correct behavior known.
About your co-worker: the proof is in the pudding. Get some Moose under your belt, whip up the schema code for your DB with DBIx::Class::Schema::Loader::make_schema_at, and show him what it can look like with a little test suite for your demo.
When you do this, you're preparing many tools that you don't even know you need yet too; db versioning, object abstractions and serialization, fat model logic, extensible classes with roles and constraints... Jump into the Perl renaissance with both feet!
In reply to Re: Help me avoid writing C Programs in Perl for a living
by Your Mother
in thread Help me avoid writing C Programs in Perl for a living
by cleverett
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |