tags:

views:

39

answers:

3

hi,

im looking to create a web app using php, mysql. im planning to write it in classes.

i have created 3 classes: CBaseUser, CWaiter, CBaseAuth

so basically CBaseUser will be a parent class to CWaiter and CBaseAuth contains things like GetPasswdLen(), CreatePasswd(), GetToken().

so right now im heading to do the rest of the program which requre insert,delete,update, login, etc

im a little confuse here because im not sure where should I do my sql query function. should i do it in CWaiter?

could someone enlighten me about OOP in PHP? like the best practice to create a PHP web program.

+3  A: 

If you are doing all OO you might want to take a look on php's pear db before going deeper into sql transactions. pear::db makes possible to do database agnostic systems, meaning that you can run it on mysql, postgre, etc without changing a single line of code.

Rodrigo
great!! i look into it now
A: 

im a little confuse here because im not sure where should I do my sql query function. should i do it in CWaiter?

You could, but it is generally considered good practice to keep your SQL queries in a separate place (ie separate set of source code files) to your business logic.

"MVC" is a pattern people often talk about which involves separating the code for "Model" (ie anything that needs to know your database structure, eg all your SQL) "View" (anything that draws the UI, which typically means the template engine) and "Controller" (all business logic, drawing it all together).

This would mean that you'd have a different group of classes with names such as CBaseUserDB or CWaiterDB (or whatever) for anything that needs to update/query the database. This is a simplified example just to illustrate my point.

The thinking behind separating this is that SQL, template code, and business logic all intertwined can be messy or hard to follow.

You may also want to look at PDO which is a more modern way to access a database than for example mysql_ and mysqli_. It contains some extra features such as prepared statements, but the main benefit in my opinion is that it means your knowledge will be more future proof and you'll be able to adapt to different database APIs easily. Unlike the previous answer I don't much fancy higher level abstraction like pear::db but that's up to your personal opinion.

thomasrutter
+1  A: 

See here for a similar question. You really want to avoid repeating structurally similar queries, but too few programmers know how to do that in a 'greenfields' project.

staticsan