Zitat von Richard Jolly <[EMAIL PROTECTED]>: > I think we will end up making a domain/business layer on top of DBIC. > But it's a shame, in a way, because DBIC is nearly good enough as is. > We'll want a to continue to be able to write code like this: > > $episode->broadcasts > > So if we make a domain layer we have to duplicate all the relationships > already defined in DBIC. You can see this as a good thing, in that we > are constraining the API, giving us a good testing point, etc. But for a > lot of it it seems like making life more difficult for no real benefit.
I just re-read a thread about the pros and cons of introducing a separate business logic layer on top of the DBIC (persistence) layer: http://www.mail-archive.com/[email protected]/msg01157.html I can see the advantages of this and want to give it a go. I decided to create my business classes in MyApp::Model::* and I'm now wondering what's the best way to provide them with the needed storage connection infos to make DBIC (which is called in these business logic classes) work? This was previously done in a standard way via C::M::DBIC::Schema but because this is dependant on Catalyst (and my business classes shouldn't be) this approach is not going to work anymore, is it? --Tobias _______________________________________________ List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class Wiki: http://dbix-class.shadowcatsystems.co.uk/ IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/ Searchable Archive: http://www.mail-archive.com/[email protected]/
