Oops, sorry ; I accidentally hit « send » too fast !
Since youre using DBIC, I suggest you take a look at the cat tutorial section on CPAN about exploring the power of DBIC : http://search.cpan.org/~hkclark/Catalyst-Manual-5.8004/lib/Catalyst/Manual/T utorial/04_BasicCRUD.pod#EXPLORING_THE_POWER_OF_DBIC Youll learn how to create your own resultset classes, thus allowing you to use clean & concise method calls in your controllers, instead of ever growing DBIC queries. If you were to use your other (non dbic) classes as catalyst model, I would suggest you use Catalyst ::Model ::Adaptor, Which allows you to do things like package MyApp::Model::SomeClass; use base 'Catalyst::Model::Adaptor'; __PACKAGE__->config( class => 'NotMyApp::SomeClass', args => { foo => bar }, ); Which I, for one, find to be pretty neat. http://search.cpan.org/~bobtfish/Catalyst-Model-Adaptor-0.08/lib/Catalyst/Mo del/Adaptor.pm Have fun J Regards, Morad IGMIR De : Morad IGMIR [mailto:[email protected]] Envoyé : jeudi 27 mai 2010 15:00 À : 'The elegant MVC web framework' Objet : RE: [Catalyst] Refactoring question If youre using DBIC, De : Steve [mailto:[email protected]] Envoyé : jeudi 27 mai 2010 14:38 À : The elegant MVC web framework Objet : Re: [Catalyst] Refactoring question On 5/27/2010 3:51 AM, Morad IGMIR wrote: Hello Steve, I think your business logic should be moved to the model, not the controller. The model does the heavy lifting. My model is currently comprised only of my DBIC Result and ResultSet classes. Are you suggesting that some of the logic in my controllers should be moved into my DBIC classes, or should I create new Moose classes. If Moose, how do I 'hook up' those classes to Catalyst? Your controllers would be easier to maintain if they only did simple tasks like dispatching, calling models and forwarding to views, as said on the catalyst wiki : "Decouple as much as possible. If you have to fire up your web application in order to test database insertion, that's wrong. Build the model so that you can use Perl one liners to manipulate data through it." http://wiki.catalystframework.org/wiki/best_practices#Follow_the_Catalyst_di et:_thin_controller.2C_fat_model. I know it's easier said than done when you've spent time building huge controllers, but it really pays off. Your comments are appreciated, as I'd like to learn some lessons before moving on to my next application, which is going to be much more involved. Thanks! Regards, Morad IGMIR -----Message d'origine----- De : Steve [mailto:[email protected]] Envoyé : mercredi 26 mai 2010 22:39 À : The elegant MVC web framework Objet : [Catalyst] Refactoring question Hi all, I'm searching for general advice on Catalyst app design. I've been studying all the banter on this list for almost a year, and have finally gotten to the point where a real live application is underway. Being a newcomer to web dev in general, and also that this application wasn't originally supposed to go into production, I didn't give app design much of a thought (controllers in particular). The app I'm writing generates HTML invoices/statements for individual subscribers. The database consists only of 4 tables: users, roles, user_roles, and invoice_data. Don't laugh too hard, but I called my first controller 'WebUsers', and a second one 'ViewStmt'. The authentication is remarkably similar to the examples I've seen :) As you might imagine, the WebUsers controller is starting to bloat as it has to maintain users, log them in/out, and basically handle all the 'heavy-lifting' for the application. The ViewStmt controller basically handles the rendering of a statement, and is quite manageable. There are only two roles: administrator, and individual. Individuals can log in/out, and view their own statements - period. Administrators on the other hand need to administer the users, so basic CRUD for that part. They also can view statements for anyone, so I've got a nifty list that gets presented, and links to individual statements. All of the logic for handling this functionality is in the WebUsers controller. I'm wondering if I should refactor all of the user maintenance stuff out of WebUsers, and into its own controller, or just deal with it as * this application won't ever be expanded on * . Thoughts, advice, wise-cracks are all welcome :-[ Ce message entrant est certifié sans virus connu. Analyse effectuée par AVG - www.avg.fr Version: 9.0.819 / Base de données virale: 271.1.1/2880 - Date: 05/26/10 08:25:00 _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
_______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
