I am seeking a good argument for:

Why is it NOT a good idea to embed data retrieval code in my view?


    <td><select name="product">
        <option value="0">--</option>
        $sql = "SELECT id, model FROM product";
        $result = db_execute($sql);        
        for ($i = 0; $i < db_num_rows($result); $i ++)
            $row = db_fetch_array($result);
            ?><option value="<?=$row['id']?>"><?=$row['model']?></option><?

I can somewhat theoretically understand that things like "compartmentalizing" individual code constructs in their own respective boxes (such as creating classes for individual View, or persistent storage) can be beneficial, but then having code in the same place is also beneficial. I can see everything right here in one place. Data is pulled in the same place where select box is rendered. I see localization (of code that creates the select box in one place) of as a good thing.

Properly separating (i.e. refactoring this code) means creating a Model, Controller, Data Storage, View constructs and all the other boilerplate code which goes along with it, where literally 4, 5, 6 or more classes must come together to execute the very same functionality.

3 Answers 3


What happens if two separate views need to display products?

What about code that needs to modify products?

Separating out the retrieval code so it returns proper model objects allows the code to be reused. Code reuse means it is implemented once, and cannot get out of sync in multiple locations, where some have bugs and some do not.

A view should be more of a template without any real logic in place other than constructs such as loops that directly control the view (i.e. "for each product, show this element").

As a project grows, it is easier to find, edit, and fix code when separate concerns are separated. Code reuse becomes easier, code correctness is easier to test.

Seeing the code all in one place is a weak argument:

  1. You should be able to have more than one editor window visible at a time. You can have the view and its model in separate windows both visible. The age of low-resolution, square monitors is past.

  2. By having the code interweaved like this (view, model, view again) you are actually making it more difficult to see in a way: the view (web page, in this case) is fragmented because of the code embedded in it. If you want to see how view elements display in relation to each other you have to overlook the code which is in a different language. This is why even JavaScript code should be externalized to a separate file, despite being tightly coupled to the view (it was written to manipulate the HTML DOM).


In the mid to late 90s, your style of web programming was a lot more accepted, for exactly the reasons you stated. It's simpler, more consolidated, with less boilerplate. In fact, PHP's easy enabling of this style is a big reason it became so popular. When we talk about the benefits of separating model and view, we shouldn't forget there's also a significant cost we're paying in the trade off. The cost is worth paying, but it's still there.

The consolidated style works well for very small, infrequently changed pages, but as you scale, the costs start to outweigh the benefits. If you have designers working on your pages, it becomes more difficult to integrate their work with yours. Small layout changes might adversely affect the model, and vice versa. Avoiding duplication becomes very difficult. Things like making a mobile version of your site becomes very difficult. Figuring out what ripple effect a change will have becomes difficult. Unit tests become more difficult to maintain.

Yes, you have some extra up front costs that are annoying, but over time you are better off. Plus, you actually end up with code that's more focused and easier to read, which hopefully means you don't have to jump around between your different files so much.


Do you see front-end code inside your back-end? You do not. You could have it there, but would that be comfortable? For most back-end developers it would be not. As a back-end developer myself, I am very comfortable with reading classes, methods, seeing connections among them, etc. Front-end code would polute the back-end code and make it way harder for me, as a back-end developer, to read.

Considering I, a back-ender, do not like dealing with front-end code, I am quite sure (and it is in fact that way) the same applies vice versa to front-end devs.

The other thing is separation of concerns, as Snowman has already pointed out. You have a bug in PHP? All you're going to be fixing are .php files. Bug in JavaScript, open up a .js file. You want to change the way front-end displays data? You touch .html (or your template) files.

Still, even though I am greatly influenced by enterprise designs, if I was making a very simple application, really simple, I'd probably just dump everything into one file just to get it done. But if you go as far to adopting the MVC architecture, you should respect the conventions and do specific operations in places, where they belong.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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