[Catalyst] Catalyst::Model::DBIC::Schema or not?

Brian Kirkbride brian.kirkbride at deeperbydesign.com
Fri Mar 23 21:36:22 GMT 2007


Alejandro Imass wrote:
> 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: clean, powerful,
> maintainable access to your database, in fact, anything that pushes
> the ORM a bit too far should go IN the database. In practice, you will
> find that many of the procedures stored in the model classes will
> probably wind up in the databse for performance issues, so what I have
> done is set the boundary right there from the beggining (the point
> where you feel that you are pushing the ORM a bit too far). Any
> complex business logic should always be in the DB (if you are using a
> decent database such as PostgreSql, Oracle). The power, encapsulation
> and performance gains of using views and rules on a RDBMS like
> PostgreSql is without question. Unless you _really_, _really_ have
> serious portability issues, and not willing to maintain several sets
> of DB code, always consider programming the complex stuff in the DB.
> 
> Cheers,
> Alejandro

I think maybe I didn't explain myself very well in the early email.

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.

Best,
Brian



More information about the Catalyst mailing list