|
On 5/27/2010 3:51 AM, Morad IGMIR wrote: 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?Hello Steve, I think your business logic should be moved to the model, not the controller. The model does the heavy lifting. 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.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. 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/No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.819 / Virus Database: 271.1.1/2898 - Release Date: 05/26/10 14:26:00 |
<<attachment: steve.vcf>>
_______________________________________________ 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/
