in reply to Re: Catalyst : Observations After Week 1
in thread Catalyst : Observations After Week 1

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
  • Comment on Re^2: Catalyst : Observations After Week 1

Replies are listed 'Best First'.
Re^3: Catalyst : Observations After Week 1
by perrin (Chancellor) on Nov 16, 2005 at 18:36 UTC
    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]

        Well, MVC on the web is severly limited anyway.

        In real MVC apps, the view can listen to changes in the model, and has to, because there are often multiple views and controllers interacting with the model at once.

        On the web, once you’ve rendered the view, it sits there dumbly in the user’s browser. (XMLHttpRequest does not significantly change this.) That makes the distinction between the model and the controller blurry and somewhat artificial.

        Makeshifts last the longest.

[reply]
        I don't think your split of "taking care of data, getting stuff done, and showing data" actually reflects the intent of MVC. It does reflect how most people use Catalyst though. I would expect an MVC app to have a controller that does nothing but map input to methods in the model. It would know nothing about the application itself, but plenty about the web, i.e. the point of the controller is to separate things that are web-specific about user input from the model. That is all it should do. If you want to run your model from a Tk GUI, you just make a new controller and view that understand Tk.

        We do have a bit of a problem at this point, since no other useful name has evolved for the style of development you are talking about. Calling it MVC isn't accurate, but calling it "a templated web app with an O/R mapper" is not succinct enough.

[reply]

In Section Meditations