4

I have an application built using an MVC framework (for argument's sake, PHP/Yii2) and have a question regarding where to carry out logic and generate values which will be injected into, for example, IndexView or AboutUsView.

In this instance the 'About Us' page is displayed when the route /about-us is hit by a browser, calling the actionAboutUs method in SiteController which simply calls the method Controller::render($template) causing the $template php file to be parsed and output.

This is fine when the content of $template is not dynamic in any way; just static html content. However when there should be dynamic content my understanding of MVC is that this should be computed in the controller and passed to the render method.

To be truly MVC is this correct and if so a hard and fast rule?

For example, in a page I'd like to output the number of posts which a class method Post::getNumberPosts() could be called in the view directly and output or called in the controller, assigned to a variable, the variable injected in to the view and the value of the variable output. Does the first method go against MVC as a pattern?

Or if on the homepage I'd like to output one of two different messages depending on the logged in status of the current user. If the user is not logged in a generic welcome message or if they are logged in, call other methods to generate user specific content. At the moment this is being handled in the view in the following manner

 <?php if (!App::loggedIn) { ?>
    <p>Generic Welcome!</p>
 <?php } else {
    $myVar = currentUser->getDetails();
 ?>
    <p>hello <?php echo $myVar->myName;?></p>
 <?php } ?>

Could this case be handled in a more MVC manner?

tl;dr All logic in controller and pass to view?

7

Firstly, your View certainly shouldn't contain business/application logic. Its responsibility is for layout, appearance, and presentation of data. Whenever you come close to thinking "Hm, should I add an if statement into my View?" the right answer (as far as MVC is concerned) is No!.

Secondly, your Controller really should not contain business/application logic either, because its responsibility should be limited around acting as the "glue" which serves up the view after an inbound request from the user.

The best place for business logic tends to be in your model (which is really more like a ViewModel than an ORM Model).

The MVC pattern itself is not intended to cover the structure of your application logic; that logic may well be split into multiple layers (including Models, ViewModels and other things), but MVC is a UI pattern, and not a pattern to describe your complete application architecture.

Anything which isn't related to user interactivity (such as business logic) is generally lumped under the loosely-termed umbrella known as the 'Model' as far as MVC is concerned.

  • 1
    The fact that MVC is a UI pattern is not recognized by many people. You mentioned that business logic tends to be in the model (which is really more like a ViewModel) --- this gets a little tricky. Your ViewModel should not have business logic in it. It should have display/presentation logic. Otherwise +1 – Greg Burghardt Mar 10 '16 at 21:38
0

As Ben has already described it the view should be more or less dumb. Ideally, no logic should be here. To better support this approch an own templating system has evolved called Mustache. It is implemented in many programming languages. Find more information here:

http://mustache.github.io/

https://en.wikipedia.org/wiki/Mustache_(template_system)

Directly creating views with PHP (and Yii2) allows you to do all what is possible in PHP. This may lead to not so clean view files, but honestly, this makes daily life sometimes a bit easier.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.