Large Scale PHP Application Design Questions

[Jesse Burns]

I'm about to start working on my first large scale site (in my opinion) that
will hopefully have 1000+ users a day. ok, this isn't on the google/facebook
scale, but it's going to be have more hits than just family and friends.

Either way, I'm planning on this site blowing up once I have enough of a
feature set, so I'm concerned about performance and scalability in the long
run.

I've worked for a software company, but I've never programmed PHP
professionally (looking for an entry level job, wink wink ).

I was wondering if sites like Sitepoint, MySpace, Facebook, etc... actually
use DB abstraction layers and template engines.

I also plan on using the code for this site for my portfolio, so I'd like to
have as much original code as possible, that's why I'm not even considering
using a framework (I've dabbled a bit with CakePHP and ZF), so I won't
bother asking about using them for large scale sites.

I've been doing a lot of research, and it seems to me that using PHP as a
templating engine itself and creating my own DB class using native DB calls
(going to use MySQL until I find it no longer suites my needs) would be the
most efficient approach.

I do plan on separating Data/Business/Presentation logic to make maintenance
easier, so that's the only reason I'm considering using a Template engine to
separate the Business/Presentation layers, and then either PDO, ADOdb or
PEAR::DB for the data layer.

But once again, I've come to the conclusion that using pure PHP to separate
the Business/Presentation layers, while using my own home brewed DB class as
the data layer would be the best way to go regarding
performance/scalability.

Are there professionals out there with experience working on large scale
sites/applications that can lend their two cents?

[larry]

On Oct 22, 10:36 am, "Jesse Burns" <jburns...@jbwe bware.comwrote:
[snip]

>
I've also included my "includes" folder in php's include_path, which was a
great suggestion, thanks. I have one question on that. My "includes" folder
is located outside of my doc_root, but since it's in the include_path in my
php.ini file, can people still access it that don't have root privileges?

You can set an .htaccess file to restrict anyone outside from
accessing files in the folder except localhost (or something to that
affect) so include will work but not user links (I just learned about
that one, have to re-arrange some files...)

I know that I'm not thinking of everything that I'll need in the future, but
I hope that I have enough knowledge at this time to make changes in the
future as painless as possible.

....

I know I haven't touched on a few suggestions posted here, but that's
because I'm still mulling them over and doing my research.

Heres a big tip, now that you have a good beginning of dos and donts,
START WRITING CODE!

Research and theory are nice for a lunch or evening conversation but
practice is where you will actually get your skills polished and
things get done. Some of this stuff may not work for you or you may
discover your own styles. Getting good at programming takes actually
programming a lot.

Also pain happens, regardless of what you know, just think of it as a
challenge, and know you will be getting some real-world hard-knocks
skills tackling those problems.

Once again, I'd like to thank everyone for their feedback. It is much
appreciated.

Sounds like you are off to a good start.

[Hugh Oxford]

Jerry Stuckle wrote:

>Prefix all your objects with $obj_

I disagree with this part. While it's important to give meaningful
names, I think $customer for a Customer object works well. Then use
something like $customerId for a customer's id (which is probably an
int). I just don't see a good reason to complicate things with $obj_
prefixes (plus it makes documentation that much harder when you have a
lot of objects prefixed that way).

It's a personal thing I suppose. I just like to know when I'm dealing
with an object.

>

>Objects should always have get and set methods for all variables.
IMHO, you should never access variables directly from outside the object.

Agreed - all variables should be private.

>The exception to this is using the __get magic method, which I have
found enormously useful. To give you an example, let's say you have a
customer object and you want to be able to get any property of the
customer eg. $obj_Customer->name and $obj_Customer->balance.

In this I somewhat disagree. I don't like the __get() and __set()
methods at all. It complicates the code.

>You can put a switch/case in the __get method so you can abstract away
anything behind the scenes. So $obj_Customer->name can bring back a
concatenatio n of firstname and lastname, $obj_Customer->balance can
call another object to do more work and return the balance, and so on.

Which is exactly what I'm referring to above. You don't need to use the
__get() method to do this if you have the methods already instantiated.

There's a time and a place for it. I never use __set because I want the
flexibility to be able to validate inputs to methods. In fact, I only
have one class which uses __get, but otherwise it would have countless,
and in my opinion redundant get methods.

The class in question is one which gets customer details. As the
functionality of the application grows, simply adding another case to
the switch statement does the trick.

public function __get($var)
{
switch($var)
{
case 'foo':
// do stuff to get foo
break;

case 'bar':
// do stuff to get bar
break;

default:
throw new Exception("Cann ot get $var");
break;
}
}

So there's no confusion or ambiguity, and a lot of flexibility without
loss of clarity.

>Then $foo['sdf'] becomes $foo->sdf. Much nicer to use. You can also
create new data objects on the fly using new stdClass.

I don't like this, personally, but won't argue that much with it.

I agree, it's just a matter of taste. I prefer fewer brackets and quotes.

[Hugh Oxford]

Jesse Burns wrote:

I've also heard (and believe) that the likelihood of throwing away the first
draft and having to start again as you learn what works and what doesn't
work in large projects like this, is a big likelihood. And that's fine with
me as long as I'm learning in the process.

It's funny you should say that - I'm in the process of rewriting an
enormous system which has been successful, will end up looking exactly
the same as the old one and will do the same thing.

It had become unmanageable. I was using an a fairly monolithic system
which worked up to a point, but for the project to go forward it needed
ground up rewriting.

My advice is come up with a simple framework into which you can drop new
pages at will. What has worked for me is to have an index.php which uses
the 'section' variable of the URL to both load up an include file at the
top of the script (for the business logic) and another include file for
the presentation logic (html).

The advantages of OO are enormous. Classes and objects don't just offer
encapsulation, they offer flexibility. You can pass objects to one
another as method arguments, act upon them.

Just don't fall into the trap of writing "God" classes which are
infinitely flexible and general, just because you can. I actually have a
ObjectVerb naming convention for all my classes - CreateFoo, DeleteFoo,
UpdateFoo, often as children from abstract class Foo which might be too
much for some but works for a simpleton like me.