----- Original Message ---- > From: Eden Cardim <edencar...@gmail.com> > To: The elegant MVC web framework <catalyst@lists.scsys.co.uk> > Sent: Tue, 23 November, 2010 0:59:18 > Subject: Re: [Catalyst] Begginer's question about application structure > > >>>>> "Martin" == Martin Bendix <martinben...@yahoo.co.uk> writes: > > Martin> My model should be well separated from the controller. > Martin> Most, if not all of the application functionality should be > Martin> exposed via the model, so that the Catalyst controller only > Martin> needs to make simple calls to the model. To do this, model > Martin> classes should be created in 'lib/myapp', with simple > Martin> adapters in 'lib/myapp/Model', using > Martin> Catalyst::Model::Adaptor. > > Controllers need to act as an adaptor between the model and the > view. So, for instance, mapping $cd->artist into a value that's suitable > for placing in a form field "value" attribute is the responsibility of > the controller (cos' when you change the UI into a CLI switchboard, for > instance, the mapping is going to be different). > > Martin> At this point, I am a little less clear on how best to structure >my application. > > Martin> As my models will be primarily concerned with accessing the >database, how much > > Martin> database code should go in my model classes, and how much in the > Martin> DBIx::Class::ResultSet classes? For example, should I write a >method in my > > Martin> DBIx::Class::ResultSet classes that can add new CDs when > supplied >with title, > > Martin> artist and a track list? Or would it be better to put this in > my >model? > > You need to constrict the scope of your methods as much as > possible. That is, try not to write any code that makes the ResultSet > aware that it's being used in a web application. I find that most of > DBIC's API is well suited for being invoked directly by the > controller. You just need to avoid any constructs that make the > controller aware that there's actually a relational database behind the > model, because then you're free to swap out to an alternative > implementation. A general rule of thumb is to try to avoid writing > complex ->search methods in the controller, put those behind a > friendlier method on the ResultSet, for instance write a resultset > method that allows you to write $cds->released('this year') (which you > can implement via DatetimeX::Easy) instead of > $cds->search({ 'YEAR(me.date)' => DateTime->now->year }). > > Martin> Data validation could be handled by HTML::FormHandler, but > Martin> any validation performed here won't be of much use if I > Martin> later provide an alternative interface to my application. I > Martin> assume that I should therefore delegate validation to my > Martin> model as well, so that the same validation methods can be > Martin> used no matter what the interface? > > I'm of the opinion that using form generators puts you through the same > amount of trouble than writing/validating forms by hand, so I just dodge > the HTML::FormHandler thing altogether, but that's just me, YMMV. > > -- > Eden Cardim Need help with your perl Catalyst or DBIx::Class >project? > Software Engineer http://www.shadowcat.co.uk/catalyst/ > Shadowcat Systems Ltd. Want a managed development or deployment >platform? > http://blog.edencardim.com http://www.shadowcat.co.uk/servers/ > > _______________________________________________ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ >
Hi Eden, Thank you for your reply. It's good to know that so far I have been thinking along the right lines. I've received some great advice so far, and your post is no exception. DatetimeX::Easy looks like another very useful module to add to the collection - yet another example of the wonders of Perl and its great community :-) Regards, Martin _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/