Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Re^3: The Model View Controller pattern in web applications

by pg (Canon)
on Oct 24, 2004 at 22:29 UTC ( #402094=note: print w/replies, xml ) Need Help??

in reply to Re^2: The Model View Controller pattern in web applications
in thread The Model View Controller pattern in web applications

The same simple idea is behind all those concepts: to modulize things. Start from wrapping code in functions, to OO, to MVC, this is all about modulization.

When the web application is no longer just a bunch of static pages, or something relatively static like shipping cart or a forum like this, it becomes too complex for things like CGI etc. Once again, people need to simplify what they are dealing with and the way they looking at the applicatin. MVC comes in.

Model can be simply understood as the data (could be database, a flat file, a set of XML's), or activities against the data (for example a query, or an upadte, an OO method against a dataset object, a SOAP call, a Java Enterprise Bean...)

View is the window for you to see the data and its transition.

You need something to glue your model and view together, or I would rather say to seperate them, but yet attached. Now here comes the controller. As you said, for a web application, this is where your requests got handled.

There are lots of challenges when you do web application in MVC way. My experience tells me that one of the biggest challenge is the cost. If you want to do everything right (everything MVC), with the tools you have now, the effort is hugh. No free lunch!

  • Comment on Re^3: The Model View Controller pattern in web applications

Replies are listed 'Best First'.
Re^4: The Model View Controller pattern in web applications
by Joost (Canon) on Oct 24, 2004 at 22:53 UTC
    I agree on most of your points, and I know from experience that MVC can be a huge and costly effort. :-/

    I do think that for smaller CGI applications it can still be beneficial to try and separate the three components, because in my experience, those are just the kind of apps that get coded before they're designed.

    If you take something like CGI::Application, I think it will make a big difference already for those apps. Even if you don't do the full MVC separation.

    Bigger and more complicated applications tend to get more design time anyway (ignoring an abundance of contrary examples), and are _hopefully_ more maintainable just because of that.

      Put in this way:

      • From an abstract view: CGI is a totally different animal than MVC, and it is even not a design pattern, but rather a functinal part of a system.
      • From a practical view: I agree that CGI can be used to implement part of the MVC model, especially the V and M. If we are talking about Perl modules, then yes, we can use CGI::Application, even CGI. If you look at what CGI (the perl module) provides you with MVC in your mind, you will quickly realize that:
        • It can be used to form view, with methods like start_form, h1 etc. But I would largely prefer templating systems.
        • It can be used as part of controller, with methods like cookie etc.

      However if the developer or designer has too much CGI in his mind, then most likely he would come up with something does not clearly sepearte M and V.

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (2)
As of 2018-05-26 03:33 GMT
Find Nodes?
    Voting Booth?