[Catalyst] How many models?
jjn1056 at yahoo.com
Thu Apr 26 21:29:15 GMT 2007
---- Original Message ----
From: Jamie Neil <jamie at versado.net>
To: catalyst at lists.rawmode.org
Sent: Thursday, April 26, 2007 10:47:46 AM
Subject: [Catalyst] How many models?
We're in the process of porting an existing CMS/Cart system to Catalyst,
and trying to work out how to deal with the database modelling. While
most of the tables will be accessed through a simple DBIx::Class::Schema
setup, there are a few which have more complex relationships that we
wish to hide behind custom methods.
We've come to the conclusion that this is best done by creating an
external module, but we're not sure whether we should create two
Catalyst models (one using DBIx::Class::Schema and one wrapping our
external module), or have a single model and access the simple tables
through the external module too. The first option seems simpler more
straightforward, but we don't want to end up with multiple database
connections (there is only one database) if we can help it.
Can anyone offer some advice?
Jamie Neil | <jamie at versado.net> | 0870 7777 454
Versado I.T. Services Ltd. | http://versado.net/ | 0845 450 1254
I think the consensus is that it's best to create business logic type models outside of Catalyst and then build a simple wrapper model for it. That way you can use it for stuff like cron jobs and anything that doesn't live inside of Catalyst.
Whether you put those additional business logic methods inside the actual DBIC Schema class or in a separate class is your call. Best practices suggest that it's best to kept the physical ORM cleanly separated from your business logic classes, but if you don't have a lot of logic or if your physical model is a very good representation of how the data is actually used then sometimes it's easier to add a few methods directly to your DBIC Schema classes.
Usually I create a tree structure similar to this for new applications:
[Under .../Myapp-Application or something similar]
Web.pm (Catalyst Application package)
Schema.pm (Your DBIx::Class::Schema)
Users.pm (a DBIx::Class)
Tags.pm (another DBIx::Class)
Accounts.pm (A Plain Old Perl Module)
DBIC.pm (Loads up Myapp::Schema)
Accounts.pm (A Wrapper for MyApp::Logic::Accounts)
Now I isolated the business logic for creating an account into the MyApp::Logic::Accounts package because for my system creating a new user is much more than just inserting a row into the Users database. The logic would using the MyApp::Schema::Users Class and some other classes and wrap all that into a neat interface. However you could probably put a lot of that logic into methods in the MyApp::Schema::User class if you wanted to. I'd probably do this is there wasn't a lot going on in this process since I don't want class explosion like you get with Java development sometimes. Also there is something to be said for putting stuff where you might expect to find it and I think I'd like in the User class first for stuff like that.
I've been putting all my catalyst components under a namespace like 'MyApp::Web' or 'MyApp::Portal' etc rather than keep the directory structure flatter because this way it's easier for me to make multiple catalyst instances sharing a given set of libraries. There are other ways you can do this but I find this way the most simple. YRMV.
The only issue I have here is having to write all the wrapper classes for Catalyst Modules that instantiate a Logic Module. However it probably wouldn't be too hard to write something to do this for you automatically, similar to the way the DBIC.pm creates Catalyst models for each DBIx::Class you have. If anyone has some thoughts on this I'd enjoy hearing it.
Anyway, that's what I do, but I'm probably far from the expert Catalyst guy on the list. Hopefully this will spawn some discussion.
List: Catalyst at lists.rawmode.org
Searchable archive: http://email@example.com/
Dev site: http://dev.catalyst.perl.org/
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
More information about the Catalyst