On Thu, Apr 26, 2007 at 10:02:24PM +0100, Jamie Neil wrote:
> John Napiorkowski wrote:
> >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.
>
> That's exactly what we're trying to do.
>
> >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.
>
> Again, this is the direction we are going, however what I was concerned
> about was that this way we would end up with a lot more database handles
> that was necessary (we may have three or four models). Whilst this is
> not a problem for a single application, we are planning on running many
> instances sharing the same database server.
>
> Of course I may just be misunderstanding how DBIx::Class works :)
Just make sure your applications share the DBIx::Class::Storage::DBI
object between any $schema instances they're using - then they'll all use
a single persistent $dbh.
Alternatively, just make your logic models get their DBIC objects via
ACCEPT_CONTEXT (see Catalyst::Component) at which point everything's running
through the one DBIC::Schema model eventually.
--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director Want a managed development or deployment platform?
Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote
http://www.shadowcatsystems.co.uk/
_______________________________________________
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
