Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

Re: Catalyst : Observations After Week 1

by chromatic (Archbishop)
on Nov 12, 2005 at 22:14 UTC ( #508033=note: print w/replies, xml ) Need Help??

in reply to Catalyst : Observations After Week 1

The Controller does the real work. Controller handles biz logic ("You can't give a raise to a fired employee"). The Controller handles the flow through the app.

I don't really consider that MVC. (It's just a pattern, so if that works for you, great! However, in my experience it's not the right approach.)

The nice part about MVC, as I see it, is that you can re-use the model for different applications. That is, you have all of the business logic in one place. It's easy to see that you can change views, but if you have a different application that should allow fewer or different operations on the same data with the same underlying business rules, you can write a different controller.

Again, it's just a pattern and how you use it depends on what you need to do.

  • Comment on Re: Catalyst : Observations After Week 1

Replies are listed 'Best First'.
Re^2: Catalyst : Observations After Week 1
by Anonymous Monk on Nov 13, 2005 at 03:59 UTC
    You can set up your Catalyst models to be just that. For many users, their Catalyst "Model" component is just a DBIx::Class or Class::DBI stepchild (with table-specific model-specific functions and whatnot) with a fancy module/class name. They reuse that same model code both from the Catalyst MVC framework and from other non-web components (like cron jobs doing database maintenance, or backend servers that log data to the same database the Catalyst app is viewing).
Re^2: Catalyst : Observations After Week 1
by water (Deacon) on Nov 13, 2005 at 14:42 UTC
    I don't really consider that MVC. (It's just a pattern, so if that works for you, great! However, in my experience it's not the right approach.)

    Say more, please!

    Would you suggest this should live in the model, so other non-web-apps can call $obj->give_raise(or whatever) and for free get the logic ("no raises to fired emps", for example)?



      Yes, exactly that.

      I once maintained a reporting application that pulled data from a multi-application database. There were no constraints or integrity checks in the database or the applications people used to enter or edit data.

      One day in 2003, my contact at the customer called me to yell that the report listed records from 2005! I told her that the reporting program had no hard-coded dates in it and that the errors came from her database. I also gave her a single SQL query to run to prove it. I'd previously given her another small application to find and correct as many data errors as safely possible -- and there were plenty.

      Granted, calling any of the applications MVC is a real stretch. Still it is painfully obvious that putting business logic (you can't add a record with a date in the future) where other applications can't reuse it can cause plenty of trouble.

      Of course, if you know that you'll never ever access your data with any other application ever, go ahead.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://508033]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (6)
As of 2018-06-24 20:50 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (126 votes). Check out past polls.