http://qs321.pair.com?node_id=508249


in reply to Catalyst : Observations After Week 1

There is a nice page on the wiki about this introductory stuff and particularly about the use of the MVC acronym in Cat. Personally I agree with nothingmuch at #catalyst irc channel:
model should be the most complex reusable thing you can do without wasting time
For me it means that business logic should go into the model - but there are people that use some other definition of business logic. Generally it is usefull to reuse the model class in cron job or some other administrative scripts.
  • Comment on Re: Catalyst : Observations After Week 1

Replies are listed 'Best First'.
Re^2: Catalyst : Observations After Week 1
by nothingmuch (Priest) on Nov 15, 2005 at 10:13 UTC
    For me it means that the model represents a thing that does lots of work to make it easy to modify, but that it contains no decision making code whatsoever. High level business logic - the things that relate to the user (what data to retrieve for a request, what modifications on the model to do on behalf of the user), is in the controllers. Static policies, that are always enforced, like parameter validation, etc, can be mixed between the model and the controllers depending on context. The structure of the data is completely in the model.

    -nuffin
    zz zZ Z Z #!perl
[reply]
      That is a common interpretation, but it is at odds with the traditional definition of MVC. Decisions, parameter checking, etc. all go in the model in MVC. The controller is just a generic thing that maps input (HTTP requests) to method calls.

      Most recent frameworks take this approach, making the model the dumb part (generic object-relational mapping layer) and putting all the application logic in the controller. It seems to work fine. Catalyst's controllers would probably be called part of the model by the traditional MVC definition, but it's just semantics after all.

[reply]
        I think this is because GUI frameworks allow controllers and views much more tightly coupled and complex - UI kits are bigger, more flexible, and much more "manual" than the web, where browsers take away a big piece of the job (reducing your options, ofcourse). There's another issue in "real" UI applications - the chronology is more easily intertwined. With web apps the interaction is much more spaced out and separated (i'm not really sure how to say this).

        Because we have to deal with far less technical complexity in web applications, we can take the lesson learned from MVC - that most applications can be easily broken into 3 layers that relate to taking care of data, getting stuff done, and showing data, and that furthermore breaking an app down like that will probably help the design and maintainability of the application.

        Since the parameters involved have all changed applying this lesson to web applications merits reinterpretation, or at least that's how I see it...

        What's your opinion on MVC in the webapp scene? How do you write your apps? What's your opinion on the meditation above?

        I think it's interesting to understand how MVC evolved so much in this scene... I have not written UI programs (only maintained them - and they were badly designed), so I actually had no idea MVC in that world is so different.

        Lastly - I disagree with the model being the "dumb part". I usually try to make the model slightly more than just a mapping layer - it gets some application specific features, and many times it's not even database related. This is where the quote that got me into the thread makes sense to me - the model should take the technical load off the controller, as long as it doesn't over-abstract things (wasting time).

        Thanks for the interesting comment =)

        -nuffin
        zz zZ Z Z #!perl
[reply]

In Section Meditations