Structuring PHP Code

[nickCR]

Hello All!

I have been coding PHP for 2 years now and modding scripts about 5 years before that. I have a decent idea of what i'm doing as far as the actual coding is concerned (one of the sites I coded is getting 1000's of transactions a week without any problems so far and 2% avg cpu usage).

With that being said I never took a course or anything of such I just learned on my own as I went along. This may or may not mean I am coding things "right" so I wanted to ask some specifics about how things should be structured.

Currently the setup i'm using is very much along these lines:

classes (all the classes and configs go here behind the public_html folder)
public_html (all the pages go here, some pages have on page code but some don't depends what needs to be done with the information before I send it to the class)
.htacess has a php file prepend which includes a file which then includes all the classes and dependent classes.

As for the classes. I use two classes for client interface code, one for code (logic) then another for database inserts, selects, etc. The logic code is the only one that can access the database since it's set as "private".

Now with all the talk going on about stored procedures etc, i'm curious if it's worth it to start transferring my database code to stored procedures and eliminating the database class (i'm using MySQLi 5.something.).

Oh I also have an HTML only class which basically renders any HTML code that needs to be returned through a function.

Anyway that pretty much sums it up. Maybe some direction or guidance. Even a that's fine, not worth the trouble to convert is acceptable :).

Thanks in advance,

Nick

[httpwebwitch]

You're already doing more & better than most PHP 'grammers. You've obviously thought about your structure and have made some good decisions.

Personally I don't like using global prepend... but I suppose it could be handy if you *really* want all your scripts to include the same family of classes. I don't always want that. So instead I load classes using include() or require_once().

What you're doing is already similar to a well established pattern called MVC (Model/View/Controller)

Here are some links:
Wikipedia - [en.wikipedia.org...]
Java - [java.sun.com...]
Microsoft - [msdn.microsoft.com...]

As for the database class... well hey if it ain't broke, why fix it?
Stored procedures do help some people prevent SQL injection. But you can easily prevent SQL Injection using old-school query construction; with validation and escaping. I hope you have done so in your db class.

I don't know of any claim of increased speed or efficiency. If there are, that would be a compelling reason to do it.

Sometimes I'll do things like that if I get bored and I want to see how the technology works. An exploration that offers no improvement over what was there before. Sometimes that's enough of a compelling reason.

There are probably some useful things you can do that have a better payoff... like optimizing images, decreasing download time, investigate caching strategies, validate your HTML, give your site a CSS tuneup, compress your JS, set up a source control repository for your work, etc.

Then again, there is also an argument for stepping away from the computer, going for a walk, or spending some time visiting friends with wine. Mmmmm, wine. Goes well with pizza.

[WesleyC]

I'll second using an MVC pattern. Once you use MVC for a while, you'll never want to go back. At this point, I cringe whenever I have to deal with a PHP file that has business logic, HTML, and database access code mashed together. The separation MVC gives you makes things so much simpler to code, and much easier to change later if something changes. If your business logic changes, for instance, you can usually just change a controller or two and all is well in the world. Likewise, if you decide to completely change database systems, all you have to do is update the database library used by your models and you're off and running again.

I also agree with httpwebwitch in one other matter--if your existing system is that efficient and well-planned (it's better than much of the existing PHP code out there, by your description) already, it's probably not going to get any faster, even if you convert to a MVC design. In fact, the MVC design may slow it down a hair due to its usage of objects in areas that you may have previously handled with inline code. If you're looking for speed improvements, learning more about CSS, Javascript, HTML, the HTTP request cycle and headers, caching, .htaccess construction and optimization, and other performance tweaks will give you plenty to work on. Tools like Firebug, YSlow, and the Web Developer toolbar will give you plenty of information about what may need improvement on your site.

So far as using stored procedures, I've seen a lot of hype about them, but very few compelling reasons for switching an existing site to them. Yes, they prevent SQL injection attacks--so does a good query templating system, or proper input validation, or simply calling mysql_real_escape_string( $inputVar ). They can be a tiny bit faster in some cases, but in the great majority of situations queries return in around 1 ms anyway. Any speed increase you get here will be negligible in the request cycle unless you're running 100+ queries on every pageview, so your time is probably far better spent on some other aspect of the site.

[nickCR]

Thank you both for your detailed replies!

My code is designed in an MVC concept-ed pattern with a few mods to make it work for me.

Luckily I followed a good base to start from and have always liked the code flow that it follows and for that reason I stuck with it (as Wesley pointed out).

My CSS is well tuned but the javascript is not my forte, was actually thinking of hiring someone to optimize just that.

The HTTP request cycle sounds interesting and I've never played with that. Definitely need to look into that and caching.

I felt that stored procedures would help separate the DB code even more from the php code and since the stored procedures are there why not use them but the time it would take me to move them all over based on your comments is definitely not worth it especially since I have implemented all the mysql_escape_string etc...

I guess i'll need to read a bit about mysql_escape_string and mysql_real_escape_string to get a clear understanding which I need to use and where.

Thanks again for your comments and i'm really glad (and relieved) to see that i'm doing things right.

I'll take your advice and concentrate on optimization to speed up what I can where I can.