Jason Gottshall wrote:
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.
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).
Best,
Brian
_______________________________________________
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/
