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

[Alejandro Imass]

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 <brian.kirkbride at deeperbydesign.com> wrote:
> 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
>
> _______________________________________________
> List: Catalyst at 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/
>