Why Kevin Yank put the code in different files (Templates and controllers)?

[CS Geek]

Hi.

I would like to argue why Kevin in his book has put the PHP code in different files (Template and controller)? Is that considered a good practice? what is the main reason behind it? Is related to MVC pattern?

And finally: will it affect the performance of the site?

[Pullo]

Hi there,

I presume you are referring to Sitepoint's "PHP & MYSQL From Novice to Ninja (5th Edition)"

I would like to argue why Kevin in his book has put the PHP code in different files (Template and controller)? Is that considered a good practice? what is the main reason behind it?

As far as I understand it, the reason for this approach is to separate your app's logic from the presentation of the data.
This pattern helps ensure separation of concerns of your code and in most cases will steer you clear of 'spaghetti php' where your app's logic is tangled with the HTML generation.
The modularity of this approach also means that you can easily reuse various pieces of your code on both your current and future projects.

Is related to MVC pattern?

I'm not sure of the name of this pattern, but, as it's implemented in the book it's not MVC (or at least, if it is, it is missing the model (M) part).
Maybe someone else has an idea?

And finally: will it affect the performance of the site?

Not in any way which will be noticeable. If your site is starting to slow down under high traffic, this is one of the last things you'll need to worry about.

[ServerStorm]

Hi there,

I presume you are referring to Sitepoint's "PHP & MYSQL From Novice to Ninja (5th Edition)"



As far as I understand it, the reason for this approach is to separate your app's logic from the presentation of the data.
This pattern helps ensure separation of concerns of your code and in most cases will steer you clear of 'spaghetti php' where your app's logic is tangled with the HTML generation.
The modularity of this approach also means that you can easily reuse various pieces of your code on both your current and future projects.



I'm not sure of the name of this pattern, but, as it's implemented in the book it's not MVC (or at least, if it is, it is missing the model (M) part).
Maybe someone else has an idea?


Not in any way which will be noticeable. If your site is starting to slow down under high traffic, this is one of the last things you'll need to worry about.

Yes the idea of separation is what he is outlining in this part of the book. The template is part of the View code, the controller is part of the Controller in MVC. You organize your files and your thinking into these rough categories. It can help you better think-through what is model, what is controller, and what is view code/functionality.

Generally when you mix or couple your model, view and controller code together then it becomes harder to debug and your code is less flexible and resilient to change.

MVC is not the only separation model that exists, but the important thing to understand is that effort to separate your code into meaningful functional concerns generally leads to better code.

Regards,
Steve

[aaarrrggh]

I can tell you from experience that the MVC model works very well for most websites and web applications. What may seem like extra effort to you now will save you so much time and effort in the long run.

Example: I'm working on a site right now that is going through a total redesign from the user experience view point. A design agency is going to be changing the design of the site for us, and me and my team will be incorporating the changes into our application (it's a complex app and the design agency are just changing the user interface - none of the actual database code or anything like that).

Honestly, I'd estimate the entire thing will take us about 2 days to do when the design comes through. This is because our changes only impact the view part of the MVC - so the models and the controllers do not need to change at all. Our application will look completely redesigned from a user's perspective, but we won't have to touch the underlying database code at all, so it's really easy.

If we had these mammoth php scripts where the html and application logic and database stuff was all just stuck together randomly, we could spend over a month (or longer) working on this redesign. I look at code posted here daily and know for a fact I'd hate it if I had to work with it.

MVC is great. Invest some time and effort into it and things will start falling into place for you :-)