PHP MVC - One view class for all controllers vs a view class for each controller

Question

I am creating an MVC inspired PHP framework, mainly for learning purposes. I basically have the framework created and am building an app on it and improving the framework as i go along.

I am still confused/not sure about certain aspects of this sort of architecture, and at the moment i am questioning my implementation of the View part.

How i have set up my framework:

Its a very simple set up, for example: you go to the url /post/post_id, this will load index.php which will instantiate the router. The router will then check the url and instantiate the correct controller and method based on the url. In this case it would be PostController, and the method would be a default method that would use the post_id to get the posts data from the relevant model. Next the controller would set up a "data" variable that will hold the data to pass on to the View, and this is where i am confused - should it send to its own View object (a view class file dedicated to the PostController), or to a generally used View class that is used by all controllers to load an html file?

At the moment my controller is sending data to the View class, this data includes what template file should be included/shown, and the actual data for the page (what we got from the Model through the controller).

My question is this:

Should this type of system have one View object that renders all of the views (html files) based on what data is given to the "render" method, or, should each controller that eventually sends data to the View have its own View object/class?

Meaning, should PostController send a request to the general view class, the same one that is used by all controllers to renders pages, or should the PostController send to a dedicated View Class (call it PostView if it makes it clearer), and this class will then render the specific html file?

Basically if it should be one View class for all controllers that will render what ever html file the controller tells it to, or if there should be many View classes, one for each page load.

NOTE: I know a lot of questions have already been asked about MVC in PHP, but i could not find an answer to my question in any of the answers.

Answer 1

I will try to answer some of these questions. Having a single View Class helps makes the code easier to maintain if they share a lot of components. For most of the pages, it's common to always have the same header and footer. This is only different in pages that require authentication. For example, a login page will have its own header and footer.

In this design, the View class will have the render method to allow you to set the footer and header. Your mandatory parameters will be the main file and the data.

static function render(
  $main_file, 
  $data, 
  $header='default_header.html', 
  $footer='default_footer.html');

So with that, you only need one line on every controller that needs a view.

// inside LoginController
function Show($id){
  //...your regular code here

  // renders view 
  ViewClass::render('login.html', $data, 'login_header.html', 'login_footer.html');
}

// inside PostController
function Show($id){
  //...your code here

  // no need to specify header and footer
  ViewClass::render('post.html', $data);
}

To take care of dynamic contents inside the header and footer, I use hooking strategy. This means my PostController and other authentication zone extends another BaseController class that loads header and footer data.

It may seem like a lot of boilerplate code, but the other advantage is that you can change the view to render JSON without affecting your controller logic.

// inside PostController
function Show($id){
  //...your code here

  // now loading json templates
  ViewClass::render('post.json', $data, 'header.json', 'footer.json');
}

One more point is that true MVC design is meant to make it easier for your designer to work on the views. If you create classes for every view, it has implications on the designer's involvement. Designers should not be writing your classes.

Answer 2

Well the question to this answer is simple and is not relativ to the MVC at all:

All views or controllers share some logic. So they inherit something from a master view or controller class. And then extend it with their specific stuff. Everything can be done with solely one class and just work with flexible methods. The question is, when does it make sense to make it flexbile and when does it make sense to create a fork. If you think they have significant differences in the methods that are required or setup they are used in, it make sense to fork it.

So question yourself, what view class 1 and view class 2 have in common, why and how should they differ. If you come to the conclusion that they are basically identical, only use one. If the are different, create a master and let them inherit it and extend it with the specific stuff. Same for the controller.

And that's basically the answer whether you should use one or multiple. The reason you do not find an answer to it simple is, that the question is wrong. It is unrelated to MVC. It's simply related to another part of your architecture.

In general if you do not find an answer to a topic where you think there should be an answer to it, most likely you ask the wrong question and try to question your question instead. Think about what conclusion brought me to my question and go backwards.

However, as this is something very basic about code architecture, you should also go further:

Sometimes instead of having multiple classes you can work with objects instead. Create different instances of the object, use different data and it works properly for each type. Whether it's static or an object basically depends whether it make sense to enrich it with information or not. If not, it's static. If yes, it's an instance. If you need to behave differently and doing it as an object is too complex for some reason, make it a class instead.

Depending on your implementation, you even may end in having a class each just with different instances of the view and controller classes. Everything depends on your implementation and how you want to use it. Whether it's static, an instance or a class has nothing to do with MVC. MVC just describes a specific relationship between them and a specific task for each one. Nothing more.

There is no ultimate best practice, nor an answer that always works best. Think yourself about what is the best in your situation. Most often you do not need the answer right away. Then make it as modular as possible for easy refactoring. As you do it for learning, try different approaches and learn from their up- and downsides.