I think you already got a couple of good answers but I want to chime in-
Catalyst rules. You can have any number of models you want. You can have DBI, DBIx::Class, Rose::DB, XML::Feed, 10 external webservices, etc, etc, etc all living together. Most of the examples show DBIC but there are no limits and the framework encourages (though doesn't force) good design choices and separation of the models. In my main personal application I have DBIC as the main model, a plaintext/line-record model for some simple human editable stuff, and I've gone through four different models to represent external feeds as my needs evolved. The only Cat assumption about models is that the model shouldn't need to know about the application (though it can if you really need it) and that the application has nothing to do with the model except for instantiating it (with configuration and arg passing) and using its "API."
Mason v Catalyst can be Catalyst + Mason. Mason is a fine view layer for Catalyst. Catalyst supports arbitrary views too. I've worked on apps that use both Mason and TT2.
Cat has a learning curve but it's fantastic and the only thing it locks you into is its dispatch mechanism which is extremely flexible and hasn't let me down since it got an overhaul about 2 years ago.
In reply to Re: Catalyst versus Mason
by Your Mother
in thread Catalyst versus Mason
by zerohero
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |