... 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__
[download]

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.

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

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.

No sweat. I just followed up to address the issue to the OP (specifically, the OP's concern that inter-component changes in MVC must somehow be a hassle).

I must admit, however, I was a little surprised that you did not define Model to look something more like:

my $data = [
{type=>'fruit',food='apple'},
{type=>'veggies',food='carrot'},
{type=>'meat',food='bacon'},
];
[download]

or

my $data = [
[qw(fruit apple)],
[qw(veggies carrot)],
];
[download]

This is the approach I tend to use most often (with obvious anticipation that "M" will be eventually migrated to a database). I almost always use AoH in fact.

Yours breaks the MVC separation because the Controller now needs to know that the Model stores its data in a hash ...

Perhaps, although I don't think it necessarily 'breaks' the pattern to introduce simplifying assumptions about M (especially in tutorial-type code examples like here). Unless your MVC framework always uses reflection, or a sufficiently expressive and universally disambiguating syntax, your V and your C are going to have to know at least *something* about your M.

Anyway, I just figured you were trying to save some typing ... (which is why I didn't even bother to give a code example at all in my first response ;-).



=oQDlNWYsBHI5JXZ2VGIulGIlJXYgQkUPxEIlhGdgY2bgMXZ5VGIlhGV