Personally (and this does mean personally), I'd do it as follows:
Your actual "logic" code (e.g. the whole deal of storing and retrieving
things from the database) should be in a separate set of modules. Call
those the 'backend' stuff. The main module here should be able to
connect to the database on it's own, given the location of a config
file, and it should be able to take an existing configuration and DB
handle from Catalyst;
e.g.
my $backend = My::Backend->new(config_file => 'foo.cfg');
or
my $backend = My::Backend->new(config => $c->config, database => $c->model);
(the above isn't quite correct but forgot what I used myself).
Then you can easily wrap that into a Model; and do things like:
$c->model('Backend')->get_me_an_artist()
The advantage here being that you can also use your backend outside of
Catalyst, so writing a console app becomes trivial at that point.
Sorry for the slightly disjointed reply but doing about 234413 things at
the same time :D
Martin Bendix wrote:
Hi,
As a Perl and Catalyst novice, I have recently completed the online Catalyst
tutorial, and read the Definitive Guide to Catalyst. However, I have a few
questions about the basic structure of a thin controller, fat model application.
I'd like to take my learning to the next stage by writing a fully functioning
application, and the classic CD database seems like a good place to start - it
will at least be of use to me when it's done.
Given the following basic criteria, I would be grateful for some high-level
advice on how best to organise the application:
* I will be using DBIx::Class to access the database.
* At first, the initial user interface will be web based.
* I'd like to structure the application so that I can add additional interfaces
with relative ease in future (e.g., command line, web services, etc.).
* I'd like to create test scripts for as many of the modules/application
functions as possible.
* The application will provide the ability to create, search, update and delete
artists, tracks, and CDs.
I think that my understanding of the following is correct, but I would
appreciate any advice or pointers:
My model should be well separated from the controller. Most, if not all of the
application functionality should be exposed via the model, so that the Catalyst
controller only needs to make simple calls to the model. To do this, model
classes should be created in 'lib/myapp', with simple adapters in
'lib/myapp/Model', using Catalyst::Model::Adaptor.
At this point, I am a little less clear on how best to structure my application.
As my models will be primarily concerned with accessing the database, how much
database code should go in my model classes, and how much in the
DBIx::Class::ResultSet classes? For example, should I write a method in my
DBIx::Class::ResultSet classes that can add new CDs when supplied with title,
artist and a track list? Or would it be better to put this in my model?
Data validation could be handled by HTML::FormHandler, but any validation
performed here won't be of much use if I later provide an alternative interface
to my application. I assume that I should therefore delegate validation to my
model as well, so that the same validation methods can be used no matter what
the interface?
Are there any good tutorials out there that cover this sort of thing? At the
moment, I'm more interested in best practices for structuring a Catalyst
application than in the details of the code itself. Are there any good open
source Catalyst applications that I can look at to help me with this? I've had
a look at MojoMojo, but it's a little too complicated for me at the moment.
Many thanks,
Martin
_______________________________________________
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/
--
Ben van Staveren
phone: +62 81 70777529
email: [email protected]
_______________________________________________
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/