How to implement separation of concerns in large PHP projects?

greenie2600

My current job involves, among other things, maintenance of a very large, very complicated PHP application. It is, to be frank, a monstrosity. Little attention (or, at least, little intelligent attention) was given to architecture at the beginning of the project - so the thing is flawed on some very fundamental levels, and correcting these problems would basically mean rewriting the thing from scratch. It's all held together with chewing gum, duct tape, and prayer.

This is a prime example of what I'd like to learn not to build. I've been programming for quite some time, and most of the code I write is worlds better than the atrocity I've just described - but I still feel my way through architecture design more or less by instinct, and my designs do tend to spring the occasional leak as the project develops. I'd like them to be bulletproof.

All the stuff I've read talks about n-tier architectures, Model-View-Controller, etc. As far as I can tell, this stuff is just talking about separation of concerns - and I can fully appreciate the reasoning behind that goal. However, I haven't really figured out how to implement these ideas in the context of a PHP web application.

What am I looking for here? Do I want a framework? Do I just need to switch to a less script-kiddieish language, such as Java? Would you like me to rephrase my question in an even vaguer, more hand-waving fashion?

etully

Greenie, I have no answers for you but, in AOL fashion, "Me Too!". I'm in the same boat, could have written the same email, hand waving included. And I'd love to know where to go to learn to build a project that could be considered well designed. After seven years, my boss has even suggested that it's time to clean everything up. Wouldn't know where to begin.

Do I need to go back to school? Are there any great books? Is PHP just not suited for this?

NogDog

Migrate to PHP5 if you're still on PHP4, learn how to use PHP5's improved object-oriented features, and take a course or two in object-oriented design. (Whether using PHP, Java, C++, Python, etc.; simply using classes and objects does not in and of itself magically produce well designed, modularized, and loosely coupled applications.)

greenie2600

Hi NogDog -

Thanks for your reply. I use a mix of PHP4 and PHP5. I'm pretty comfortable with the OO stuff in PHP4; I've dabbled in the new PHP5 stuff, but haven't really leapt into the deep end of the pool yet.

Unfortunately, the time and money to take classes is not available to me right now. Anyway, I've learned everything I know on my own, and I know I can conquer this too if I can just find a good grip on it somewhere.

I've found tons of theory on this subject, but precious few concrete examples. I totally understand the end goals of (say) an MVC architecture, and the rationale for pursuing those goals, but I have basically no idea what such a solution would look like in terms of the actual structure of my PHP code.

If you could outline such a thing, even in the broadest strokes, I think that'd help me a lot. Would my PHP page consist of one main object, whose data members include other objects that handle various concerns (presentation, business logic, database, etc.)? Or would these various objects exist in parallel (i.e., in the same scope)? Or something else?

I think one of the problems I want to solve - not the only problem, but one of the bigger ones - is the task of simulating a state-based system in the fundamentally stateless environment of a Web page. Lately, I've been shifting a lot of the interface logic to the client side (i.e., fancy JavaScript), which means I have to keep track of fewer states on the server side, but I'm not really happy with that solution. Not sure how directly this relates to the subject at hand.

If you could give me two paragraphs explaining the nuts and bolts of building an MVC architecture in PHP, I'd be infinitely grateful 🙂

Weedpacket

Welcome to the Big Ball of Mud 🙁🙂