Elegant PHP Architectures?

akweboa164 asks: "I work as a lone developer creating small to medium scale PHP/MySQL websites for different clients. I have been doing this for about two years now, and have tried different things as far as website layout/architecture goes. With sites that use the fusebox architecture, front controller (thanks J2EE), N-tier, to having a simple 'include(config.php);' line at the top of every file, I am left with the feeling that all of the sites I have created are 50% elegance, and 50% nasty kludge. I am left with a sinking feeling because I know that they could be better, but I lack to expertise and experience to make them that way. I am looking for overall architecture that is open and fits within the constraints of PHP (ie. relying little on OO) and separates logic, makes updates easy, etc. I wanted to ask Slashdot's crowd of web developers what their most elegant code layout/design web solutions were, and what advice would you dish out to new developers, as well as seasoned professionals."

Comments

web apps just aren't there yet

[MikeRepass]

I feel ya.

Personally, I deal with different technologies, using ASP.NET (the horror!) to craft a rather random assortment of inhouse management tools for an IT organization, but many of the issues we face are the same. From ye olde days of ASP 3.0 with the ugliness of "includes" to a modular, n-tier approach, I'm always left with an unshakeable feeling that things could have been done better. The kludge that is modern web application interface (that is to say, HTML, J(ava)Script, etc) are too scattered and poorly supported to make anything approaching an "elegant" web application. (Btw, I'd love to be proved wrong here ...).

Here are the few suggestions I have which I can confidently say have improved my productivity. There probably the same things that everyone has come across, but maybe if I throw them out here I can invite some discussion.

Separate the task-at-hand and its implementation logic from the presentation layer. For instance, I normally write all of my business logic and database code as if it were just going to be an entirely separate library, and not particularly targetted towards web dev. This not only enforces solid library design principles, but allows me to debug and test using simple command line interfaces to the library. Approaching your code from a new direction (in this case simple user apps) frequently opens up entirely new ideas and perspectives. Once you've done this, the majority of your "behind-the-scenes" web code can just be a wrapper for this library, and then all you have left is the presentation logic. This has helped me immensely in the areas of scalability/integration and portability.

Second, never ever do any cosmetic presentation work until you're absolutely sure you have a beta (or better) quality base of business logic you're prepared to stand by. Adding the presentation logic to a web app too early is sort of like munging in command line options to a good ole console app: if done improperly, things quickly get out of hand and you have to code in more global scope hacks than you'd like to admit. Personally, after many bad experiences with this problem, I do *all* my testing on blatantly ugly hand-crafted html pages until I'm sure I've got things right.

Third, don't focus on a "page" as a discrete, targeted development object. Rather, the actual pages should be afterthoughts. Try to engineer solid "user-interface" components, and then plan on the final web pages as simple composites of these components. I estimate that, when I sketch out my initial concept of the pages and interface layer of a web app, more than 50% of the various tasks presented to the user will change drastically in scope before I'm even done developing. You realize that certain tasks just aren't needed, certain things are inconvenient, etc and using a component model to the presentation layer helps reconfiguring immensely. One of the biggest frustrations with web application is that, when different ideas are flying through your mind, its difficult to figure out all that must be coded in order to test them out. You think, "hmm this might work!" and find yourself having to chase down random bugs and make changes in five different files just to get a prototype working. Using a component model helps quite a bit in this department.

In terms of architecture, the only vaguely successful model I've come across is (once you've got a solid library backing you up...) model your application as a set of distinct user tasks. Allow each task to develop independently, and the step back and look at where the overlap is and what components are a good candidate for integration. Taking things on a task-by-task basis at the beginning helps immensely in bug detection also, because you're only focusing on one coherent progression of logic at a time.

I realize that most of this is probably old news to any qualified web dev, but this is the stuff I have to continually force myself to do after two years in the biz, so perhaps it is of some use. Any comments, suggestions, rebuttals, etc I'd be glad to hear.

Mike

Some suggestions

[Alpha27]

I like PHP alot for web development. I found it easier and less to code when compared to perl (I've done both for 3 years each). You've made a good choice with it. I haven't tried python, but i do hear good things about it.

One important advice I would give is.... learn from your repetition. Meaning.. if you see that you code very similar functions or code segments that very ever so slightly, maybe there's a new function in there, that could emcompass them all.

For example:

• writing tables: I wrote a class to take an array of array, and spit out a table structure. Beats having to write echo statements with td tags, mixed with variables.
• simple dababase functions: I've knocked out a number of lines using simple code that does the same 3 steps into one function.
• object oriented code: definitely helps out.
• apply theory/concepts to work: I've seen the Model/view/controller example applied to non java languages. As well you can use cool things like XML/XSLT to handle data/presentation, there by allowing for multiple display formats.

some times the elegance is in the hack. I rewrote an art project at the company I work for, using our product for the front end, and php for the backend within 6 hours. He originally wrote his from concept to product in a year. Not bragging, just saying. =)

Look into some of the templating engines, like smarty.php.net, it's srecommended at a number of sites (I haven't used it yet), but it will allow for cleaner code, and that's what is important. Accessing code you can easily fix, and change the presentation when needed.

My PHP tips

[Imperator]

I don't claim to be an expert PHP developer, but I have spent a fair amount of time with it. Here's what I've found works:

• Every file includes base.inc.
• base.inc includes a config file based on the hostname and port--this is to allow you to use the same code to run both testing and production servers. These config files are where you keep stuff like the directories in which to store files, the database config, and so on.
• Use PEAR as much as you can. In particular, use PEAR::DB. Since you probably use the DB in every request, open it up in base.inc and store it in a global. Also, you never know when you'll switch to a different RDBMS, and if you have to modify every single call...
• On that note, use PHP OO to abstract away the DB. Do it logically, not "one class per table". This way, when you change the database or even just the schema, only the library files need to change. If it's a big multi-user project, write regression tests.
• If you're using the Zend Optimizer or a similar bytecode cache, go ahead and include all the library files from base.inc so you never have to worry about doing that.
• Use CVS. Even if it's just you.
• Use a good template system like Smarty. Just because PHP lets you mix code with HTML doesn't mean it's a good idea.
• Write your own classes to handle any common task, even for something as simple as getCgiVar().
• Keep the DB schema in one file so it's easy to read and modify.

Re:what I do...

[brianlmoon]

And PLEASE, use PHP objects. Someday PHP will be a "good" programming language with good OO features, get used to what it has now.

I hope you are not implying to use objects for the sake of using objects. I use objects where they are needed. But in a language that is not bound to them, they are not needed all the time. I remember someone wanted to have a String class be part of PEAR. Why on earth do you need a string class in a language with such great string functions? I have seen object overkill and it is not a pretty thing.

Where do I use them? When I need to keep stuff "behind the curtain". We have a class to display large tabular data that we use. It is the right choice as we just call $report->addrow("data", "data"...); and the class keeps up with it all in vars for us and there is no mess.

So, use them where they are appropriate, is my advice.

Brian.
Phorum.org

Re:Relying little on OO...?

[ptaff]

The model is still incomplete.

PHP5 promises great features, but PHP4 still lacks lots of OO concepts.

• No private/protected/public
• No static class attributes
• No abstract classes nor interfaces
• No function overloading
• Still experimental aggregation/composition

You can do OO-like stuff without the points above but at the expense of no encapsulation and ugly hacks.

Some elegant constructs are hard to achieve in PHP, a statement like this (in java) would have to be dereferenced one by one by hand:

object.person.bart_simpson.say("Bite Me!");

Somebody who has already done some OOP would be able to find workarounds but PHP would not be a good way for a newbie to learn OOP.

Re:Java View/Model/Controller

[amorico]

This makes so little sense that I can only assume that Ms. Coulter is laughing her butt off at the moderators.

There is no Java MVC for the web. You either roll your own or use Struts or Webwork or Maverick et al. MVC is a design pattern, which was correctly stated.

That, however, was the extent of any correctness. The Model is the data, which in her case would be the MySQL held data. The view would be a generated html page, JSP, Velocity Template, XML/XSLT pipeline, or whatever display technology you would use. The controller would be something that receives requests from a web browser and then decides what action to take (pull data from a database, massage it, return it, and show a results page). Accessing the data is handled by Data access objects or delegates.

If you don't know what in tarnation someone is talking about, don't moderate it down or up, just leave it.

I am going to start using that line at work though. "If we use java this way we will be akin to apple!"