Re^4: Help seperating business logic from controller (catalyst/dbic)

[uG]

This is what I was getting at. Originally I had taken the rule part and did just what you had said, put it in DB::Nation and set it up to handle exceptions. My problem at that point was I wasn't quite sure how to call a method from a Schema file (or to put it in the same namespace). I'll admit i'm pretty lost, but I can't find a good example on how to do this :(

[perrin]

I don't use DBIx::Class, so I can't help you with the mechanics of that. You could always create a separate action class that isn't part of your DBIx::Class stuff. You also don't have to use all the Catalyst window-dressing like $c->model() if it makes things more confusing for you rather than less.

[stonecolddevin]

Yea, you can put your db/model methods in a ::Schema namespace, but it all comes down to what works best for you. I don't know that you'll hear one consistent method or another, so it's best to use what makes sense to *you*. If it happens to be so far off it's going to cause you trouble, you can certainly have someone in #catalyst do a code review for you and let you know.

As long as it's reasonably sane, and most importantly, followable by others (and you!), there shouldn't be a problem.

I have however, separated my model classes into ModelName::TableName for the table definitions and ModelName::TableName::ResultSet for the "most used methods" such as specific searches (getPosts(), getUser() etc.). You have to realize most, if not all, of that is documented in the DBIx::Class::* family. Catalyst has a few pointers, but what you're looking at is strictly DBIx::Class organization/methodology (from what I've read, at least.). It gets convoluted sometimes, but the separation is there to help *you* get to the root of your question and keep logic separate, etc.

Hope this helps!