Large Scale PHP Application Design Questions - Page 2

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Re: Large Scale PHP Application Design Questions

Jerry Stuckle wrote:

Quoted text here. Click to load it

To me it's not so much about the scalability or performance of the
RDBMS, but about things like clustering and replication.

Re: Large Scale PHP Application Design Questions

Hugh Oxford wrote:
Quoted text here. Click to load it

But MySQL handles clustering and replication quite well, thank you.

Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.

Re: Large Scale PHP Application Design Questions

Jesse Burns wrote:
Quoted text here. Click to load it

I wouldn't think of 1,000 people a day as a large scale site. Maybe
10,000 a day. Certainly 100,000 a day.

I'd suggest using one of the frameworks to help guide you, such as
CakePHP, Symfony  or CodeIgniter. They have the advantage of answering
certain tough  architectural problems for you (templting, database
abstraction, etc). But if you are just learning PHP, then those
frameworks might be over your head.

Re: Large Scale PHP Application Design Questions

I just wanted to respond to all of this great feedback. I've only been this
quiet because every new post gives me one more view point to ponder.

First of all, I should point out that I'm self taught and have had no
programming classes to speak of.

First of all, I've been programming with PHP for 4 years, but I've mainly
been creating plugins for the e107 CMS in a procedural style. So I'm not
completely starting from scratch. But I have been using 3rd party
plugins/libraries for database abstraction and templating systems, and I
need to improve on my OOP.

As I am going to add my code to my portfolio (local companies don't seem
that impressed when I give them a few plugins as example code), I've decided
to home brew everything. I feel I'll learn more along the way as well.

Like I've said, I've used CakePHP and the Zend Framework, but that's not
going to teach me some of the more advanced programming principles (it is a
great example of how others do it though, so it definitely is a great
learning experience).

A lot of my object oriented experience (pretty much most of it actually)
comes from the book "How to Program: C++", which is what they use in the
local universities. The edition I have starts using OOP and Design right
away, so I didn't get stuck in the procedural way of things from the get-go.

I do believe (and have been practicing) that all class attributes
(variables) should be private, using setters/getters to access them. The
main reason for this is encapsulation, which makes maintenance so much

For example, I'm creating my DB class right now. If I need to make any
adjustments to how data is processed, all I have to do is change the DB
class and not all of the DB calls in my application code.

So when I feel comfortable that all of the database calls are working the
way I want, I can then create a validation class and filter all of my input
from forms and use those calls in my DB class. This way, when I'm creating
my application, all I have to do is use my DB class to insert data, and feel
confident that the validation class will filter input correctly. And if it
doesn't, all I have to do is alter the validation class and leave the DB
class and all of it's calls alone.

As long as I keep the DB and validation class's interface flexible, I should
rarely have to change my applications code (although I know that a first
draft will always need alterations, just hopefully not too many).

I've also decided to use the Zend Framework's Coding Standards, so all of my
private attributes start with an underscore: _dbResult.

Another thing that book taught me was to keep all of your attributes (public
and private) at the bottom of your class, because when you look at a class
later on your most likely going to be looking at the interface, rather than
the data your working on (I know that's not always the truth at all, but
once you define attributes, for the most part you're going to leave them

I've also decided to keep to a strict naming convention regarding
file/class/method/attribute names. I do plan on being the stranger to my
code in a few months time, and also hope that one day I can put a team of
developers together to continue development, and if I already have a proper
coding standard in place, it will make it that much easier for other
developers to join the project.

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?

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'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.

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.

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

Re: Large Scale PHP Application Design Questions

Quoted text here. Click to load it

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...)

Quoted text here. Click to load it

Heres a big tip, now that you have a good beginning of dos and donts,

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.

Quoted text here. Click to load it

Sounds like you are off to a good start.

Re: Large Scale PHP Application Design Questions

Jesse Burns wrote:

Quoted text here. Click to load it

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.

Site Timeline