Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Implementing Model-View-Controller

by ghferrari (Acolyte)
on Jan 04, 2006 at 12:57 UTC ( #520881=perlquestion: print w/ replies, xml ) Need Help??
ghferrari has asked for the wisdom of the Perl Monks concerning the following question:

While there are plenty of web articles on the theory of the model-view-controller design pattern, there is precious little advice available on how to implement it, in terms of structuring one's classes and objects.

So let me ask a simple question. Suppose I'm writing an application that looks up user information in a database, performs some calculations, and then outputs that information. Suppose also that for the sake of code encapsulation, I want to use object-orientation, and wrap up my code in a "user" object.

So, the practical question is this. Does it follow from the MVC design pattern that I ought to have both a Model::User object and a View::User object, and perhaps a Controller::User object, too? In short, won't I need a separate "User" object for the model, the view, and maybe the controller?

If that's so, then true, it means I can update any member of the MVC triad separately. But it also means that I must update each member separately, even if I want to make the same update to each. And mightn't that be more hassle than it's worth?

Perhaps I just lack a good idea of how to implement MVC. If anyone has any links to articles on the implementation (as opposed to merely the theory) of MVC I'd be really grateful for them.

GHF

Comment on Implementing Model-View-Controller
Re: Implementing Model-View-Controller
by Anonymous Monk on Jan 04, 2006 at 13:11 UTC
    In short, won't I need a separate "User" object for the model, the view, and maybe the controller?
    You might need 3 separate references to the object, but not 3 copies.
Re: Implementing Model-View-Controller
by Anonymous Monk on Jan 04, 2006 at 13:29 UTC
    Sounds like you might not really know the theory, or how OOP works.
Re: Implementing Model-View-Controller
by phaylon (Curate) on Jan 04, 2006 at 13:38 UTC
    There's no strict concept-to-implementation mapping for MVC, but I understand the Model as the data storage (the stuff that is controlled and viewed), the Controller as the "acting" part of that all (for the higher level logic) and the view just for interfacing. There are a couple of MVC frameworks in Perl, so you might want to take a look at them. For instance there's Catalyst.

    Ordinary morality is for ordinary people. -- Aleister Crowley
Re: Implementing Model-View-Controller
by astroboy (Chaplain) on Jan 04, 2006 at 14:17 UTC

    You'd want your calculation class (the model), and UI class (the viewer). The controller receives user input and calls the model or the viewer as appropriate.

    For instance: you could use a module like HTML::Template to provide your viewer functionality, your model would be custom written, and your controller might be implemented with CGI::Application.

Re: Implementing Model-View-Controller
by derby (Abbot) on Jan 04, 2006 at 14:25 UTC

    You don't say if you're doing web based apps or console based apps?

    If web based, I'm a big fan of CGI::Application - where it's the controller, your model is a package that defines your user object and the view is whatever template system you choose.

    You really don't want to wrap the three parts of MVC into a single OO hierarchy but you could wrap the three individually into seperate OO hierarchies.

    In practice, my controllers have always been simple derived classes of CGI::Application (I prefer to have logging embedded into the controller). The model is where I tend to get a bit crazy but it all depends on what your modelling. If you have only one user type than your model can be simply one class. The view has always been pretty simple too but then again I eschew most of the power of my template system (HTML::Embperl) and prefer a USES relationship for my template parts (headers, footers, sidebars, etc) to an ISA one.

    -derby
Re: Implementing Model-View-Controller
by dimar (Curate) on Jan 04, 2006 at 14:40 UTC
    If that's so ... it also means that I must update each member separately, even if I want to make the same update to each ... more hassle than it's worth?

    Not necessarily, the first thing is, MVC is one of those buzzwords (just like OOP) where multiple definitions apply. Asking "how do I do MVC" is like asking "how do I do arithmetic?"

    Since you are looking for practical "nuts and bolts" responses, the best approach would probably be to just understand the 'axioms' of MVC (which it seems you do) then just start coding or looking at code. Do a search for "Template::Toolkit", "Catalyst", "Smarty Templates", "Velocity", "Ruby on Rails", (etc) ... and *avoid* searching on just "MVC". The former will tend to give you 'nuts and bolts', the latter will tend to give you 'ivory tower'.

    As far as your question about the "hassle", one way to avoid it is to simply define the properties of your User object in one place, and then use reflection in your View components to automatically spit out a view. This still preserves the vaunted MVC separation while minimizing the number of breaking changes for things like adding and deleting members (or fields).


    =oQDlNWYsBHI5JXZ2VGIulGIlJXYgQkUPxEIlhGdgY2bgMXZ5VGIlhGV
Re: Implementing Model-View-Controller
by philcrow (Priest) on Jan 04, 2006 at 14:51 UTC
    You have to specify a bit more about your problem to know which way to go. So, allow me to assume you are writing a web app to manage a database.

    You could use something like Class::DBI (or DBIx::Class) as your modeler. Then you would make a module inheriting from it that describes a table in your database. That's a model. It maps rows in the database to objects in memory.

    Then you need a controller to take data from the user, validate it, calculate additional fields, etc. It interacts closely with the model, by creating new objects (rows) or updating/deleting existing ones.

    Finally, you need a way for the user to see the process. That's the view. If you design well with a templating system, you could have a set of standard viewing templates that work for many different controllers even crossing apps. For example, in our system we have a single viewing template for virtually all of our add/edit forms. The controller populates it based on business rules (should the field be visible or calculated later, etc.) and on what is in the model (does the row exist, if so, show the user the data from it).

    So, in summary, we use a model class for each table, a controller for each table (usually), and a set of stock viewing templates which are shared by many controllers (with most controllers using at least three templates: add/edit, delete confirmation, and listing of rows).

    Phil

Re: Implementing Model-View-Controller
by Joost (Canon) on Jan 04, 2006 at 14:53 UTC
    So, the practical question is this. Does it follow from the MVC design pattern that I ought to have both a Model::User object and a View::User object, and perhaps a Controller::User object, too? In short, won't I need a separate "User" object for the model, the view, and maybe the controller?

    Yes and no. For your example, you'll probably want 3 objects:

    • Model::User - interface to the user info in the database - performs the SQL queries needed to get the right data and might perform additional calculations on that data. Can be implemented using a OO-Relational library, like Class::DBI or DBIx::Class (which can save you a lot of work, since those already implement most of the low-level SQL mappings).
    • View::User - displays a Model::User object as an HTML page. This is usally implemented using some kind of templating system, not as a "hand-written" class.
    • Controller::User - processes the HTTP requests for the user data, retrieves the right Model::User object(s) and performs any needed model changes, then passes the Model::User object(s) to the View.
    In this design you do have 3 XXX::User objects, but they do not represent the same thing: the Model::User class represents and API to the (persistent) user data, Controller::User is responsible for translating requests into model actions and View::User translates models into HTML.

    update: Note that in this design, there is no User object outside the 3 XXX::User objects.

    One thing to note is that although in typical CRUD applications, like those used to demonstrate ruby on rails, there are is a single model, a single controller and multiple views for each database table, this is not the best way to design all applications. The seperation between model, view and controller is a good one, but you might want to encapsulate more than one database table into a single model class and/or use views and controllers that span multiple model classes.

    I suggest you try building a few small apllications using one or more of the available MVC frameworks to get a good feel for what works well. Most frameworks suggest a basic structure for your application on which you can build, and building everything from scratch will probably get you distracted by low-level details and it'll take a lot longer too.

    Update2: you might want to check out my article, the MVC pattern in web applications - it specifically explains the roles that the M, V and C parts play and how they interact.

Re: Implementing Model-View-Controller
by perrin (Chancellor) on Jan 04, 2006 at 17:07 UTC
    You may be getting confused by the fact that most of the current MVC web tools (CGI::Application, OpenInteract, Catalyst) are fairly different from the approach described in the classic MVC theory articles. These days, MVC for the web usually means one class that handles all the web interaction (the controller), some fairly basic classes for updating a database with Class::DBI or similar (the model), and some templates (the view). It's not exactly MVC, but it's a simple approach that works well. If you look at some of the many sample apps written with any of the three tools I mentioned, you'll see this basic approach.
        I would say that the differences in the view are less significant than the way the model has been changed. Putting application logic in the controller was not part of the original idea, but since everyone now uses basic O/R mapping tools like Class::DBI as their model, all the logic that used to go in the model ends up in the controller.
Re: Implementing Model-View-Controller
by pileofrogs (Priest) on Jan 04, 2006 at 19:01 UTC

    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

      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

      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

Re: Implementing Model-View-Controller
by jZed (Prior) on Jan 05, 2006 at 02:12 UTC
    Here's the simplest working MVC (without the OO to make it clearer).
    #!/usr/bin/perl -w use strict; package Model; my $data = { fruits=>'apples',vegies=>'carrots'}; sub get_food { $data->{$_[0]} } package View; my $template = "I like %s, especially %s!\n"; sub show_food { printf $template, @_ } package main; # Controller; for my $foodtype(qw(fruits vegies)) { my $food = Model::get_food($foodtype); View::show_food($foodtype,$food); } __END__
    You can change how the Model stores and retrieves the data without impacting either of the others. You can change how the View gets and displays its templates without impacting the others. You could use a different controller, e.g. an interactive script that prompted for foodtype. ...

      ... and to extend jZeds excellent bare-bones example, here is a slightly modified version that renders correct output even if you modify the data module. The controller and view modules still work, obviating the anticipated "hassle" posed in the original question.

      Note that the aforementioned 'hassle' really has more to do with 'loose coupling' rather than the specifics of MVC. Note also that OOP purists will not like the modification introduced here, but this is good enough to get the point across.

      #!/usr/bin/perl -w use strict; package Model; our $data = { fruits=>'apples',veggies=>'carrots' ,meat=>'bacon',grains=>'pita bread' }; sub get_food { $data->{$_[0]} } package View; my $template = "I like %s, especially %s!\n"; sub show_food { printf $template, @_ } package main; # Controller; for my $foodtype(sort keys %{$Model::data}) { my $food = Model::get_food($foodtype); View::show_food($foodtype,$food); } __END__

      Another benefit of MVC not mentioned elsewhere in this thread, is that you can put your HTML designer to work on the view (and even edit it in Dreamweaver or whatever) without them having to know how to program. This also takes another kind 'loose coupling' to pull it off correctly, as well as the politics necessary to let each team member do what they do best.


      =oQDlNWYsBHI5JXZ2VGIulGIlJXYgQkUPxEIlhGdgY2bgMXZ5VGIlhGV
        package main; # Controller; for my $foodtype(sort keys %{$Model::data}) { my $food = Model::get_food($foodtype); View::show_food($foodtype,$food); }

        You're right that my example that used qw(fruits vegies) gave the Controller knowledge of the Model. But so does yours. Yours breaks the MVC separation because the Controller now needs to know that the Model stores its data in a hash. If we add sub get_keys { sort keys %$data } to the Model, the Controller can then do this: for my $foodtype( Model::get_keys ) ... and thus be freed from knowing anything about how the Model stores things. If the Model changes to using a database, you could still have a Model::get_keys() method that would do a DISTINCT query and the Controller wouldn't need to change at all.

Re: Implementing Model-View-Controller
by ruoso (Curate) on Jan 05, 2006 at 13:47 UTC

    One first question you should do to yourself is: How big is this system?

    This question is important because this can make you choice from two different approuches...

    1) If the system is small and you just need to show the contents of a database, you can stick to the MVC used by struts, or others... wich mean that the Model object is the database encapsulation.

    2) OTOH, if the system is supposed to be a little bigger, and you're not just showing the contents of the table, but you have to deal with business rules you probably want to create a more sofisticated design...

    In this design, you would split your system in two parts, one as a Service Provider that would provide the needed services to retrieve and save the information, so you can implement multiple interfaces, or interface with other systems (see Web Services Architecture in w3c website)...

    The not-so-obvious implication is that the Model object will not necessarly represent the plain table, but could also include some calculated information, some object's relationships.

    Now to the implementation:

    The main key to MVC is a magic keyword named: "event". The key is... When the model is changed, it notifies the changes, so if the model is changed by the Controller (I mean, loading the data) the UI is updated, and if the UI changes the Model, the controller can be notified and do some extra calculation (I mean, sum the values and set the total value in the model and the UI will be notified).

    The big difference is that when you want to fetch the data to send to your service, you will not traverse all the components getting the values, the model will be already in the format you need to pass to the service, thus, reducing the complexity of the user interface.

    daniel
      1) If the system is small and you just need to show the contents of a database, you can stick to the MVC used by struts, or others... wich mean that the Model object is the database encapsulation.
      True, most MVC-for-the-web frameworks assume most of the model is implemented using an object-relational system, but struts does not mandate that. In fact, struts (like most other MVC systems I've seen) doesn't even have a built-in oo-relational library, although it does make some assumptions about your model's API. In short, you are typically free to design your model classes in any way you want (but see below).
      The main key to MVC is a magic keyword named: "event". The key is... When the model is changed, it notifies the changes, so if the model is changed by the Controller (I mean, loading the data) the UI is updated, and if the UI changes the Model, the controller can be notified and do some extra calculation (I mean, sum the values and set the total value in the model and the UI will be notified).
      Yes, and this is exactly where most web-MVC systems do things very differently compared to traditional GUI MVC systems, which tend to use Observer pattern or callbacks to link Model and View. First off, since the web mostly works with HTML pages that can only be updated via request/response actions (I'm ignoring flash), you can't really have a model update the view's output directly. Also, there are so many possible views that updating them all would be very inefficient.

      What tends to happen is that for each request, after the model has been updated, the view just queries the relevant model objects and generates new HTML/XML/whatever output.

      The exception to this is caching; cache-invalidation can sometimes handled by observing the model (however, in this case the observer responsible for clearing the cache is usually not the view or controller).

        First off, since the web mostly works with HTML pages that can only be updated via request/response actions (I'm ignoring flash), you can't really have a model update the view's output directly. Also, there are so many possible views that updating them all would be very inefficient.

        Unless you get serious about AJAX (many people bet on this). In theory, you can implement the entire MVC in JavaScript (client-side) and have your server acting just as a Web Services provider. In fact, XForms is just that, the only problem is that it still isn't supported by the web browsers..

        daniel

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://520881]
Approved by Corion
Front-paged by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (12)
As of 2014-07-30 15:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (235 votes), past polls