[Catalyst] Basic Background Question, DBIx::Class

Fagyal Csongor concept at conceptonline.hu
Sun Feb 5 14:21:57 GMT 2012


On 02/05/2012 02:21 PM, Tomas Doran wrote:
>
> 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 
> classes).
>
> 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 :)
I (also?) have a bad feeling about putting business logic into the same 
classes that fiddle with serialization. What if I want to have multiple 
"back-ends", for example?

I guess instead of MVC I would prefer something like View, Controller, 
Authorization, Business Logic, Serialization Adatpers, Serialization. 
Well, maybe not exactly like that, but you get the point. (BTW, I think 
there is really no point in the Model knowing anything about being a 
Catalyst model.)

Rob, Catalyst (and Perl, FTW) is very flexible. Use it in a way that 
suits your way of thinking. TIMTOWTDI :)

- Fagzal




More information about the Catalyst mailing list