[Dbix-class] minimalistic Moose / DBIC glue module

[Eden Cardim]

>>>>> "Drew" == Drew Taylor <drew at drewtaylor.com> writes:

    Drew> I had thought in the past about where to separate the business
    Drew> logic.  Do I do it in MyApp::Hotel or
    Drew> MyApp::Schema::Result::Hotel? Obviously canned queries go in
    Drew> MyApp::Schema::ResultSet::Hotel, but where's the dividing line
    Drew> between an operation on a Result object? What policies are
    Drew> other people using to determine this?

Generally, I try to isolate the complexity of DBIC from the business
logic, because if you ever need to add a wrapper layer around DBIC, it's
going to be very hard to mimic the DBIC API efficiently. if you have
hairy calls to search(), for instance, those belong inside a DBIC
result/resultset, then your wrapper can encapsulate that in a call
that's simpler for your business logic API to handle, something like
$cds->with_genre('pop'), as opposed to $cds->search({ 'artists.genre' =>
'pop' }, { join => 'artists' }).  As a rule of thumb, when you're
writing code in a controller or a business model, every time you have to
know/check the DBIC API docs or your schema ddl, that code should be in
a method inside a resultset/result class.  You'll find that if you stick
to this simple principle, you'll be able to use your row objects
directly, without having to use wrappers until much later, and when you
do, the transition will be smooth and easy.