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,
On Fri, 27 Apr 2007, Jason Gottshall wrote:
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
- Original Message
From: Jason Gottshall [EMAIL PROTECTED]
To: The elegant MVC web framework catalyst@lists.rawmode.org
Sent: Friday, April 27, 2007 12:54:39 PM
Subject: RE: [Catalyst] Catalyst::Model::DBIC::Schema or not?
Brian Kirkbride wrote:
Jason Gottshall wrote:
Brian
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
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
Brian,
I understood your answer, I was responding the orinial post fo Jason
Gottshall, but followed the thread from your post. Sorry for the
confusion!
Best,
Alejandro
On 3/23/07, Brian Kirkbride [EMAIL PROTECTED] wrote:
Alejandro Imass wrote:
Just my $.02
IMHO, the M is correctly defined
Jason Gottshall wrote:
Catalysters:
I'm developing a new app using Catalyst, with DBIC as the db persistence
layer. I intend to build Models that encapsulate the business logic and
that will use DBIC to interact with the database as necessary, instead
of using DBIC as a model itself.
So if I'm
It's valuable to have the model. You will get less redundant, easier to
understand/follow DB interactions and you will, if you need it, have
the DB exposed from templates and such. I don't recommend it but I was
glad to be able to write some TT code a couple weeks ago that looked
more like PHP
Just my $.02
IMHO, the M is correctly defined as is in Catalyst, and you should
definitively keep the Model. Depending on which business logic you
are refering to, the code should go in any of Controller, Model (aka
the ORM layer) or the Database.
Furthermore, I think that ORM is just that:
