I have a web application written in Perl with a controller, some views and some Models.  Each Model is corresponding to one View.  The controller (one file) creates an Model object corresponding to each view (view is a CGI argument) then retrieve the view from the module it has just created.Indeed, this should be bad thing but can you  argue a bit more about it.  My first idea was that since the object Model depends upon the view, then the model is actually a view.  But also the fact that ALL the cgi parameters are passed to the Model causes the Model to become not truelly a view but to loose all interest, since it is only related to the current implementation of the web apps.  On other words, that the Model keep model but loose its comprehensiveness (Model is not easily understandable).  I'm am quite new in project analysis, so please do not be too harsh.  Why is this bad?  I have made a prototype with the main structures I have understood of this web application, made as short as possible.#Model.pmpackage Model;import {    # this requires an attribute called view    # and this require an argument which is the cgi params}...#View1.pmpackage View1;...#Model1.pmpackage ModelView1 ;base Model;use View1;sub new {    my $class = shift;    my $arg   = shift;    Model::DoSomething($arg);    $self->view = new View1($arg);    ...}#controller.cgimy $model = 0;...     $model = new Model1( cgi_param => params() );     #there is severall models here...print $model->get_view()->get_html();
In MVC, why can't a model create a view?
mvc;perl
Consider the model being just data. It doesn't make choices, and it doesn't know how to render.A product can be a model.A list of products can be a model.A bundle containing the list of products, the cart and the information about the current user is a model.The last model from the list corresponds to the data you need to render the page, but it shouldn't know how to render itself, because it's not the task of the model.In order to render it, a view is used, given that the controller may pick different views depending on the context. It will use for example a view to render data to an ordinary guest visitor, a different view for an authenticated user, and a third view if the user is an administrator. Same data, different modes of displaying it.