Brian Kirkbride wrote: > Jason Gottshall wrote: > > Brian Kirkbride wrote: > > > I usually have an architecture like this: > > > > > > Client -> Controller -> Model -> ORM -> Database > > > > > > The ORM is usually just vanilla (as you suggested), the Database > > > enforces simple > > > data constraints (foreign keys, etc) and the Model makes > > > sure that the complex > > > business logic constraints are met. Some things are simply not > > > enforceable by a > > > stored procedure - this might involve validation of image files for > > > example. > > > The beauty of Catalyst is that it's up to you how to > > > handle separation of > > > concerns and Catalyst is helpful no matter how you do. > > > > Thanks, Brian. This is the exact structure I'm considering. So my > > question is this: If all the ORM interaction happens at the > > Model level, > > and DBIC isn't being treated as a "model" itself, is there > > any reason to > > use Catalyst::Model::DBIC::Schema to establish the db connections? I
> > guess my gut tells me "no", but I want to make sure I'm not missing > > something here. > > No problem. As I said in my earlier reply, I don't have DBIC > models in my > catalyst app because it encourages me to put ORM-related code > where it belongs, > in the Business Logic model(s). Just a follow-up to this month-old thread: I tried eliminating Catalyst::Model::DBIC::Schema in favor of having my true business Models do all the interfacing with DBIC. No problem with those Models, but I did discover an unintended consequence: Catalyst::Plugin::<whatever>::DBIC stuff stopped working! It was specifically the storage components for Authentication and Session that choked. I couldn't figure out how to give either of them the connection info they needed; they both expect to be configured with the name of a schema/table class that is then used, via C::M::DBIC::Schema, to get a resultset. So I'm trying out a compromise. I've set up the appropriate C::M::DBIC::Schema model, but don't intend to use it directly from controllers or views. Instead, I've provided all my db-interactive models with a schema()method; if the model is being used under Catalyst, they get at the schema object via the already-connected Catalyst DBIC model (thanks to ACCEPT_CONTEXT); otherwise, a new connection is composed and returned. I had to do a little more refactoring so that both C::M::DBIC::Schema and the independent models have access to the same connection logic, but it seems to be working. Meanwhile, the Auth and Session plugins are working again, and I should be able to use other DBIC-dependent plugins without problem. Now it's just a matter of resisting the temptation, as Brian mentioned, of accessing DBIC directly outside of models. I'm pretty sure I have the will power, so I just have to worry about indoctrinating the rest of the programmers in my office. Wish me luck... Jason _______________________________________________ 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/