OOP-related (but not PHP5-only)

cnperry

Here's a question on typical methodology.

My friend and I are pretty new to OOP/PHP5, and we're writing our first site together - something like a fairly simple CMS. Our question is about how people normally write OOP code (we'll just say in PHP5) for a page that prints out an article, or list of articles, from a database. It's not so much how to do it, but how should the database class (our own) interact with an article class?

We seem to agree that the actual query should be created and executed only by the DB class, but we don't know if this should be done from the actual page, or if people normally pass by reference the database object to the article object so it can do everything behind the scenes.

for example, if we wanted to update an article in the database:

$DB->updateArticle($Article->id,$Article->getValues());

versus

$Article->update();

(this object passes the values and invokes the DB query internally).

Any ideas and insights? They will be greatly appreciated!

Thanks in advance!
Cameron

jazz_snob

I've done both but lean towards $data_layer_class->update( $id, $whatever ) rather than make my objects able to save themselves. Works well for simple projects (ie logic isn't complicated, just CRUD (create, retrieve, update, delete)).

Also, there is another approach...a single gateway object to all the articles (rather than having a bunch or article objects). I've spent way too much time over-thinking solutions to simple PHP problems by applying OO techniques after reading PEAA.

Also, if there were some awesome OO design guidelines you could always turn to they'd look like this

cnperry

jazz_snob wrote:
I've done both but lean towards $data_layer_class->update( $id, $whatever ) rather than make my objects able to save themselves. Works well for simple projects (ie logic isn't complicated, just CRUD (create, retrieve, update, delete)).

It seems like it does work well (I've tried simple implementations of both), but it isn't clear whether one or the other would be preferred, especially with future application growth is taken into account. Would the self-update be preferred in situations where the application becomes more complex? At least with that method you have a good way of isolating a lot of the logic to very specific tasks.

Thanks!
Cameron

jazz_snob

Don't worry about the future, you'll cross that stream when you get there. Think about what needs to be done.

I tend to use a table gateway, and in this case Article can't save itself:

// combining basic insert, update, delete w/ common query views
class ArticleGateway {
  function ArticleGateway( &$db_conn, $table ) { }
  function insert( $title, $etc ) {}
  function update( $id, $title, $etc ) { }
  function delete( $id) { }
  // here are the 'extra' methods, basically common queries
  function find($id ) { }
  function findAll( $limit=0, $offset=0 ) { }
  function findByDate( $yr, $mo, $day ) { } //or whatever args you want
  function findByTitle( $title ) { }
}

If Article is responsible for its own persistance...then you might consider:

class ArticleFinder {
  function find($id) { }
  // pretty much the same 'find' methods from above
  // each method would probably return an Article or Article[] (array)
}

see row data gateway pattern