PHP Separation of Concerns and MVC

Question

To start with I'm not exactly sure if this question will fit the question model of SO so moderators please close it if it doesn't fit...

I have been reading a lot on MVC and SoC lately and how they relate to programming in PHP and am having some difficulty grasping how the concepts differ to my current programming style. Any application I write uses url_rewrite routes, with the routing handled by a single file which selects the appropriate controller.php file based on the sub system requested. Then within that controller file the final smarty template file is assigned and the PHP file which contains the business logic of the page in question is included into the stack.

The issue I am having is that while I review MVC and SoC information all the examples I see are written as extensive inter-dependant classes and some rather deep namespaces, but when I code I only use objects where I need an object for reusable but distinct code (in line with object examples on the PHP site itself), and so wind up with some code being classed and namespaced nearly 70% of my application remains in the global namespace with no classing. It seems to me that this coding technique still meets the design principal of separation of concerns, though i'm not so sure about being MVC as every example of MVC I can find is built solely out of a very large number of classes.

Could someone please explain if I am way off base here or if I am achieving SoC and possibly even MVC with my current coding and explain to me if embedding the entire application within a range of classes is a requirement for SoC and MVC.

Thanks

Answer 1

OK I usually take on these open ended questions :P

Let me rephrase your whole thing to a new question – and feel free to tell me I am wrong!

I think you are asking - “Is my coding style in-line with best practice for x y z?”

Now look – i have been in a variety of roles, and I strongly believe that no one has ever cracked a complete SoC architecture – at some point there is always a trade-off between enabling someone at the view end to do their job, and someone upstream ingesting the input and making it work such that it ties to the database and logic.

For example - I am actually right now building a system that takes HTML files as input, reads them via PHP. PHP converts the HTML elements to a bunch of JSON and adds logic to that JSON based on x, y and z, then shoves it out to Facebook React components – which converts it all back to HTML / DOM – when you explain to someone that there is a sausage machine that takes, as input, HTML, and outputs HTML, you can see why they might go – holy shit what are you doing!!

Now – why did we do this? Because it made sense for the project, and it made sense for the team. We could have equally used some pre-defined framework and blah blah blah – however this worked for us.

(a caveat here would be, if you need a highly performant application, this might be the wrong approach, however – bear in mind that what you read (inter dependant classes etc.) may also not be performant – optimisation of PHP code is hard work – my advice here is, get it working first, then if the product is successful, pay someone to fix your shitty code – server time is cheap – your time is not)

My statement for you would be, without concrete examples and use cases – people will struggle to comment on your approach – but understand that there are many different ways of doing things and you may see much open source code written in one way or another, but if you write something that achieves a goal, your only concern should be that it is performant and that it has ‘enough’ separation such that your designer can work on design, your coder can work on code and your CEO can look at sales figures.

Hope this helps.

Answer 2

From the information you've given, you're doing a good job. I think you have a grasp at Separation of Concerns and probably MVC. I think you should take a closer look at how things are abstracted in other codebases, how things are modularized, and think about how you would handle things that potentially come up in web development.

What if I want to have some code run before every controller? Or middleware that runs between the request and the controller? Or inject a variable into the view after every controller is processed? How are you separating POST, GET, PUT, DELETE logic but still grouping them within a resource? Some of these can be achieved with your architecture but I think many of the solutions would be cleaner with a class-heavy architecture. Of course, something being cleaner is in the eye of the beholder.

Frameworks released to the public try to be generic and tackle as many use cases as possible. One issue I see is that you make the assumption that the controller file would be called last and then setup the view. So, even though the logic in there is in the global state, it only exists within that file. In essence, the file acts as a namespace. I don't think that's an assumption a generic web framework should make, but it's something you can get away with when writing something for yourself.