---- Original Message ---- From: Jamie Neil <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, April 26, 2007 10:47:46 AM Subject: [Catalyst] How many models?
Hi All, 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? Thanks, -- Jamie Neil | <[EMAIL PROTECTED]> | 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] /lib /MyApp Web.pm (Catalyst Application package) Schema.pm (Your DBIx::Class::Schema) /Schema Users.pm (a DBIx::Class) Tags.pm (another DBIx::Class) (etc.) /Logic Accounts.pm (A Plain Old Perl Module) /Web /Controller Join.pm Root.pm (etc.) /Model DBIC.pm (Loads up Myapp::Schema) Accounts.pm (A Wrapper for MyApp::Logic::Accounts) /View TT.pm /root /script /t 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. Peace, John _______________________________________________ List: [email protected] Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/ __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ List: [email protected] Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
