Slashdot Mirror
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."
Quote:
I am looking for overall architecture that is open and fits within the constraints of PHP (ie. relying little on OO)...
Why relying little on OO? What's wrong with PHPs classes and objects?
Simon.
(a semi-newbie to PHP)
95% of all Internet endeavors go bust within the first 2 years, chances are, you won't have to touch the code again. The other 5% are all porn sites, in which case, you don't want to touch the code to begin with or maybe you do... Well dude, use a front controller like Jakarta Struts.
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
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:
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.
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:
Gates' Law: Every 18 months, the speed of software halves.
(Sorry about the code formatting. Slashdot's messing with it, and dinner's on, so no time to futz with it).
I make few claims to writing elegant PHP, and I'll generally sacrifice a few extra CPU cycles if it will save programming time. I have yet to run into a situation, even on high traffic sites, where this isn't a worthwhile tradeoff, as long as you're not writing horrendously inefficient code. If there are bottlenecks, I'll look to sections of code that are getting hit a lot and optimize on that level. You might have guessed that I'll take the performance hit and use objects if I feel like it will make my job easier. There are fancy names for most of this stuff, but never mind those for now.
What I do depends largely on the scope of the project, but there is one rule that I follow without exception. Nothing goes into the page that's being displayed but control flow statements and variable output. No assignment, no (god forbid) database calls, nuthin'.
For simple, one page, this-will-be-dead-in-a-year stuff, I put this at the top of the page:
and all the work goes into index_code.php. Beyond that, for this level of work, I don't worry much about elegance beyond the usual rules of breaking discrete bits into functions rather than allowing everything to string on for screens and screens of scrolling. This is mostly for my own sanity.
if($foo) { doStuff(); } else { doSomethingElse(); }
is much easier to make sense of than if all the work is sitting in between those conditionals.
For larger applications, I use a config file that contains any configuration I might need. Again, as little logic as possible. This is likely to be shared site-wide. An initialization file, also often shared, contains any beginning work that might need to be done. Checking to see if variables should be pulled from $HTTP_POST_VARS or $_VARS, calls to authentication routines if necessary, etc.
This will be driven from one file who's job is to figure out what needs to be done, and dispatch the work accordingly. Again, depending on scale, this may also contain common footers and headers. For bigger projects, all this does is dispatch the calls, and HTML is pulled from a template file, with content being inserted into it.
The dispatcher will call the appropriate code file and a matching file that contains the HTML and any required control flow stuff (as above) for content display. The code file doesn't contain anything "deep." Anything remotely heavy is done with classes included from a lib/ directory.
This structure gives the following benefits:
One last note. I don't use a templating engine. Things like smarty are nice and all, but with a little discipline, you can achieve the same effect with no added complexity.
Seeing as the post has a zero flame content, I will add that nothing I do in PHP ever feels "elegant." For me, PHP is a pragmatic choice (widely available). The language itself (to me) has a cobbled-together feel. I'm sure that will change as it matures, but I find that things I do in PHP often have a cleaner feel in perl. I'm learning Java, and so far I'm getting the impression of language-elegance from it as well. On a purely aesthetic level, I think the language you chose has a strong impact on how elegant your solutions feel.
This is the voice of World Control. I bring you Peace.
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
I have a wild suggestion. If you want elegant, kludge-free web applications, drop PHP. The very nature of server-page based programming (PHP, ASP, JSP, etc.), the very act of mingling your code with your markup is non-elegant. Unfortunately, there really isn't any way of separating the two in an elegant fashion, so you're sorta destined for a kludge somewhere, but there are better ways.
:)
One kludge I rather dislike about nearly all server-side programming is the necessity of a connection to a relational database. Invariably, you must get into a lower level to get your data; often you are forced to write SQL for your data, and if your database is complex your queries can get pretty convoluted. There are tools to try to make that transparent, but the cure is often just as bad as the disease.
There are better ways, however. Zope, a web application platform based on the Python programming language, is my current favorite. The big feature that I like best about Zope, aside from the excellent builtin security framework (which is head and sholders above PHP, BTW), is the persistent object database -- with it, Zope can entirely eliminate the necessity of an external database. Not that you can't connect to an external database if you really feel like it; Zope has a built in connectivity API, and there are plugins for all your favorite relational databases.
Zope has many elegant means of managing your content, from your standard header-footer includes to context-based acquisition, to the many content management frameworks already built for you on top of Zope like Plone. Zope comes with two powerful templating languages if you don't like straight Python: DTML and Page Templates.
That said, there are drawbacks: Zope is its own server, so you have to find a hosting company that offers Zope if you don't maintain your own servers. Zope.org lists a few free hosts on the main page. Using the object database is great, but because it's transactional your disk space can quickly bloat if you running a website whose data changes frequently, like, say, a popular forum or blog.
As for the language changes... if you left perl for php because perl was ugly (and believe me, I agree), then you should try python. The language is elegance personified. It's a scripting language, so it lacks the performance of Java or C++ for computation-oriented stuff, but the stuff it does, and the simplicity! Often I've seen three short lines of Python code take tens of lines of Java code to accomplish the same task. Python is so readable you rarely need to comment your code if your variable names are well named. It's also fully object oriented, but if you don't like OO for some odd reason, you can do your stuff with just functions.
Wow... what started off as just a few lines turned into a novel. Now I'm all tired and stuff. Can you tell I really like Zope and Python?
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
Using PHP objects and the State Machine concept, I have been doing some things I think are unique, or at the very least interesting.
I am unable to send you to a specific site, since the bulk of my development has been for internal sites, developer/qa tools and so on. I can however say that taking this approach has made modifying my applications significantly easier.
I would be happy to talk further with this in email. I can be reached at the email address listed in my profile if anyone wants examples.
best web host ever
Design your urls so that they're content based, and not implementation based, so where possible hide PHP from the user. Hide filename extensions from the user unless they need them. Use slashes to show content hierarchy (eg. domain.com/story/2003/6/4/ rather than domain.com/story.php?year=2003&month=6&day=4). The HTTP GET key=value pairs should be avoided where possible, unless there is no hierarchy or many items. You'll probably need url rewriting for this.
The url should pass to a script that checks the cache, and obviously request a fresh copy if it needs it.
The backend architecture depends on the app. PHP is usually for the web, and elegant architecture for HTML involves themes. Here you have three options,
Building the page as a string means that it's easier to have HTML flaws caused by one module affecting another (as PHPNuke has found). However, this is the most flexible method, if you want bizarre HTML. Dealing with strings is the older way of doing it, and I don't have much good to say about it this. In many templating engines the goal is to try and invent a simpler syntax, and then 2 years later they've implemented their own programming language. There is no such thing as simple logic when it comes to layout and HTML, and these "simple" languages often have little thought put into them, and don't allow reuse, or extensions via modules. They often end up being hacks. There are some mature examples that have solved this problem (PHP Smarty, who have simply implemented PHP in a templating language!) and these may be suitable.
Building the page using an OO means that you have a IMAGE object that has properties such as ALT text. That body object can only have certain other objects attached. You have a programatic way of dealing with a page, and you're not limited to a templating software's mini-language. However, you'll probably need to be a programmer to change the themes so you can't hand the code off to designers. It's the ASP.NET model, although there are better ways of doing it.
Building up a page in XML is elegant, in that you can refer to an XML node and attach/remove branches. You can pass nodes to PHP modules and let them attach content, knowing that all tags will be closed. You can enforce a schema/dtd on your content, and maintain a high-level language up until the moment that you publish to HTML, probably using XSL-T to theme the page.
The XML method is the best balance, IMO. XSL-T is very suited to formatting HTML, and if you want you can go to PDF via XSL-FO quite easily. I recommend building an XML file like XHTML 2.0 and then XSLTing that down to XHTML1/HTML for the cache.
As for how you handle the data, I don't really care. Personally I'm waiting for PHP5 to bother OOing my PHP.
My main gripe with PHP is that not enough is included in the default build that comes with distros and is offered for windows download. So that the generic hosts don't have the feature you need. The people who care about trim build know how to trim it more than those who don't care and end up avoiding features.
I was trying to respond earlier, but Slashdot still haven't unblocked a large...large range of IPs from posting (presumably it's not something I've done, as this account is available). Don't even bother emailing them folks, my 3 emails haven't got one answer :(
--Giving to trolls for the benefit of us all
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!"
"The plural of anecdote is not data." -- Roger Brinner
Imperator wrote:
There are some who would strongly disagree with you on this point. For some interesting arguments against templating systems written in PHP, check out this article at phpPatterns.
I've been designing PHP & CGI based online applications for a while and have come to primarily focus on one way of implementing any large scale PHP project, I haven't worked on to many smaller projects so don't know if this would be a good way to go or not.
I usually centralize the system initialization in a single file, ie index.php, system.php or core.php. This file usually performs the rudimentry stuff that all pages need, ie including config file, init database, calling authentication functions, and the basic theme display/theme stuff.
All of this is usually controlled by a serious of ojects, one for the database, authentication, and display itself are kinda the main objects, others may be implemented depending on the project.
After the system initializes itself and does the top level functions. The display object usually creates an object or includes a php file to handle this function. I usually have the system attempt to do this dynamicly based on a GET or POST value so modules can easily be added or removed.
This may not always be the best way to do it but works pretty well. It really makes it easy to add top level function to the over all system and the single file or object for actually performing system action are easily updated and can all be centralized, this create a much more module system.
I hope the third little piggy got mad cow - ^_^
As for PHP, I use:
- every file includes a common.php that defines your common functions, including one that generates a templated page.
- use front controller when I can
- data access objects and transfer objects (form and persist), with a nice generic renderer functor s to HTMLize your transfer objects.
- data-intensive classes (like transfer objects) usually end up being arrays with type signatures as opposed to actual classes. If you're using your nice generic renderers, adding a column to a result set can boil down to a change in one place. I still call the classes, though, because to me they still are (I do dispatch based on their "type").
I usually use this architecture. DB side: I have a DAO for each table used in a single-table query, along with a specialized DAO for each distinct join situation. These usually pass back a class that knows 1) the data and 2) whether it's a singular or tabular result (whether it was intended to ever bring back multiple rows). I then have a generic result renderer that will render anything, plus any specialized renderers. UI side: I have a generic form class that has a list of labels and references to the fields in the model they represent (or temp field definitions if the fields are not persistent). Then, of course, a generic form renderer + specialized. The rest is usually cookie-cutter.The caveat here, of course, is that I write mainly business apps, so consistency is the key. The genericity you find all over the place is a win for my kind of app.
[disclaimer: I'm a Drupal contributor] ;) cleanliness. /. home and withstands the load. I use Drupal to power different sites, from personal blogs to corporate intranets, and plan to use it as a base for other completely different projects.
Drupal is a CMS which doesn't use the OO features of PHP, but has nonetheless an OO design: for example all content is a "node", and you can "subclass" a node getting a story, an image, a forum topic etc.
It uses hooks so it can be expanded easily; it has both themes a-la *nuke and templates. Of course it has a good user management system.
The core is maintained by few people (not me) in a very strict, almost maniacal
It's fast and powers sites like Kerneltrap which sometimes is on
It also has a very active community.
Of course it has its own faults and deficiencies, but we are working to fix them.
Here is a recent review of Drupal.