Classes - Thought Process

[snivek]

I have just started learning about PHP classes and want to start using them.  I am struggling with understanding the thought process behind classes and not so much the code.  What I mean is...Lets say I have a Gallery section on my website.  I want to create a class for this gallery.  The backend behind it is MySQL.  Here is where my confusing comes in and i hope someone can help me out.  My class will have a LOT of dependency on the tables and columns that i have setup in the DB.  To me this kills the re usability of the class.  When I use my class connected to DB-A all my methods for selecting Albums or Deleting photos work, but when I move to DB-B which has a slightly different Table/Column setup nothing in my Class will work.  I would potentially have to rewrite all my SQL statements to insure that I call the right tables/columns.

Is there a good approach for this?  Maybe some sort of Config class?  I hope I am not just missing something really obvious!

[Jessica]

Use a config file to set the names of the tables. IE, $table1 = "myTable". When you move the code, you only have to update that one variable. $table1 = "YourTable".

Then in your SQL do "SELECT * FROM $table1", etc.

[snivek]

I have thought about that.  This is probably more of an opinion, but should I have reading and setting the config be part of the Class itself?  Maybe part of the constructor?  Or should I just read the config file with another function of possibly even another class and then pass those variables into my Gallery Class?

[Jessica]

I always have a seperate config file which has all of my settings, domain name, mysql passwords, file paths, etc.

[roopurt18]

Use a separate class or namespace for interacting with the database.

For instance, let's say you are designing some type of catalog.  I would call the catalog class CCatalog.  CCatalog would be the access point into all dealings with catalogs for the rest of your site.  It would provide the methods to create, copy, move, modify, etc. a catalog.  There is also a good chance that catalogs would need to interact with the database.  For this I could create a separate class, or at least a namespace, called DAOCatalog or DBCatalog.  This namespace / class would be a collection of functions that interact with the database.

For instance, you might have a function DBCatalog::GetExistingCatalogs() that queries the database and the actual call to this function would be inside the CCatalog class.

Whenever I create a site, I consider the site itself to be like a top level object.  It deals with all sorts of classes CPage, CTemplate, etc. to create the content.  Those classes refer to other classes CUser, CAccount, CCatalog, etc. to work with and modify the content.  All of the database interactions are buried under another layer within data access objects (DAO).

Basically, whatever you do, I recommend separating the database interactions underneath another layer.

[emehrkay]

I took the Pear approach, just excluded the xml files etc.

I have a basic class that handles all of the db queries. then i have a file for each db table, in that file is a class and each method is a query. so if i want to get a list of users from my user table i call this method

userSQL::getList();

[snivek]

So, using this approach lets look at my Gallery example.  I would create a top level Gallery Class that defines all methods that interact with the database, such as Creating/Deleting albums and Creating/Deleting Images, etc and even maybe some private validation methods?  I could then create another Class called Photo.  This class would have methods for handling photos, i.e, resize them, generate a UID, generate a thumbnail, etc.  It would also contain a method that would add this photo to the database.  This method would simply call the method that I defined in my Gallery Class?  I am following you guys?  Am I on the right path here?  Thanks!