Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re: Implementing Model-View-Controller

by pileofrogs (Priest)
on Jan 04, 2006 at 19:01 UTC ( #520984=note: print w/replies, xml ) Need Help??


in reply to Implementing Model-View-Controller

Maybe I don't understand MVC, but isn't the point to keep the M V and C separate and interchangeable? So that if you write this thing for a web page, and then later realize you'd like to write a console app, or you decide you want to use a different database, it's really easy? The User object doesn't know or care about HTML or text or whatever. There's view gunk that handles that.

So, maybe you'd have a User object, and a User::MySQL object and a User::HTML object.

And then later you write the User::Console object and the User::PostgreSQL objects.

Or am I thinking of some other acronym?

-Pileofrogs

Replies are listed 'Best First'.
Re^2: Implementing Model-View-Controller
by Joost (Canon) on Jan 04, 2006 at 19:59 UTC
    Maybe I don't understand MVC, but isn't the point to keep the M V and C separate and interchangeable?
    Basically, yes.

    The User object doesn't know or care about HTML or text or whatever. There's view gunk that handles that.

    So, maybe you'd have a User object, and a User::MySQL object and a User::HTML object.

    I think you and possibly the OP are confused by the naming of the classes. What you call User object is probably what is called the Model::User class in the OP. The Model class (whatever name it has) should be independent of the programs UI. The model is provides everything your program "does". The view and the controller provide the user interface. The view provides feedback to the programs user, and the controller translates user actions to model actions.

    Database independence of the model (if you're using a database for persistence) is mostly done independent of the model classes directly. For instance, if you're using Class::DBI to implement your model classes, you're probably using a shared base class for all your model classes which determines the type of database (excepting maybe some handwritten non-portable SQL for specific model actions).

      Okay, then if I get this right, I might create an object, called User or Method::User which contains all the internal data for a user as well as methods for normal actions on that data, like get_age() or whatever. It also contains any persistence (db) or other features.

      That's the Model.

      I'm still fuzzy on what makes the View and Control.

      My best guess is that View is a bunch of formatting functions, and Control uses both the Method object and the View functions to give you web pages. Am I right?

      For example, I want a list of everyone who has blue hair. The control might be bluehair.pl, a user callable CGI. It would instantiate a bunch of User (or Method::User) objects and use User->has_blue_hair() to pick the ones that had blue hair. Then maybe it would use CGI.pm to present the View.

      Warmer? Still missing it?

      Thanks

      -Pileofrogs

        My best guess is that View is a bunch of formatting functions, and Control uses both the Method object and the View functions to give you web pages. Am I right?
        You're quite right.

        If I'm not mistaken, in the original MVC design, the controller is responsible for setting up the view and connecting it to the model, and after that the View and the Model work mostly by themselves. But since web based applications behave differently from typical GUI applications, what tends to happen is subtly different:

        Browser View Controller Model . . . . . HTTP Request . . . +---------------------------------->+ . | . | update model . | . +-------------->+ | . | | | . | return status | | . +<--------------+ | . select view | . | +<----------------+ . | | . . | | query state . . | +-------------------------------->+ | | . | | | . return state | | +<--------------------------------+ | HTTP Response | . . +<----------------+ . . . . . .
        (see also http://zeekat.nl/joost/mvc-web/index.html)

        Basically, the controller interprets the (http) requests as model actions/queries and then passes (parts of) the model* to the appropriate view (which is selected by the controller and does nothing more than display part of the model).

        * By model here I mean all of the objects and classes that make up the API of whatever is being manipulated by the program - i.e. a database, sensors, a tv-card, whatever.

        For example, I want a list of everyone who has blue hair. The control might be bluehair.pl, a user callable CGI. It would instantiate a bunch of User (or Method::User) objects and use User->has_blue_hair() to pick the ones that had blue hair. Then maybe it would use CGI.pm to present the View.
        Yes. You've got the basic seperations right. But in most MVC frameworks in use today you would probably put most of the specifics of bluehair.pl (which might be VERY little, if you're using a good framework) in a subclass of the generic controller class and you'd use a templating system to generate the views.

        Also, if you're using a relational database, it's a lot more efficient to use an SQL query (probably implemented as a Model::User class method, and likely generated by an OO-relational library) to select a list of blue haired people instead of iterating through all users in the database one by one.

        updated: minor corrections.

        Ideally, the controller wouldn't do much here. It would read the web request, see that the action requested is a search, read the parameter hair_color=blue from the query string, and then call a method like this:
        my @users = User->search(hair_color => $hair_color);
        Then it would pass the @users data to a template for display.
Re^2: Implementing Model-View-Controller
by philcrow (Priest) on Jan 05, 2006 at 15:49 UTC
    I don't see separations like some form of MVC primarily as a way toward code reuse. Rather, for me, they just reduce the mental effort I have to expend at a given point in time. If I have a bug in validating a form parameter, I can work on it in the controller without having slog through the html that showed the form or the SQL which retrieved the old values the user was trying to edit.

    The older I get, the less I can hold in mind at a time. Separation of concerns lowers the volume I must keep in the front of my mind at an instant of debugging. If I can reuse the code because of separation, that's a bonus.

    Phil

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://520984]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (5)
As of 2021-04-22 12:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?