Brian Kirkbride wrote: > I definitely have Models, but they are a higher-level abstraction than the ORM > layer. If I understand your argument, you are advocating that data constraints > imposed by your business logic be enforced by the the DB rather than the ORM. > That's all fine and good, but MUCH lower level than what I have in my Catalyst > Models. > > 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. _______________________________________________ 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/
