[Catalyst] Basic Background Question, DBIx::Class

Tomas Doran bobtfish at bobtfish.net
Sun Feb 5 13:21:11 GMT 2012

On 5 Feb 2012, at 11:43, Rob Brown wrote:
> Shouldn't I have classes in lib/Model/ for each of my tables/ 
> models?  Is
> this what the Schema/ classes should be doing?

No, the schema is for database wide stuff.

> I'm used to creating set classes for each model in my apps, so just
> having the DBIx::Class ones is a little odd right now, with no REAL
> logic in them to model my app logic.
> I would have expected some basic wrapper model classes in lib/Model/  
> for
> each Schema/Result.
> Maybe a single class in lib/Model/ is correct, to model the entire DB,
> it just threw me a little.
> some feedback/direction would be great.

You _should_ be putting your own logic into the DBIC classes (i.e.  
both the Result aka Row classes, and the ResultSet aka collection  

Generally, you want all the 'model' logic to be reuseable business  
logic - so that you get the same data validation / api etc from  
crontab scripts...

Which means that the actual part of the model which should be catalyst  
specific is very small - just an adaptor really, and that adaptor  
generates a stub model class for each resultset you have (which is how  
$c->model('DB::SomeTable')-> then works) - but they're so tiny that  
there's no need for them to actually exist on disk.

So, basically - the answer is that the database classes _are_ the  
model, they just don't exist in the app's namespace - as being able to  
reuse them without the webapp is a very explicit design decision :)


More information about the Catalyst mailing list