Jump to content

Data Base to an Object....


corbin

Recommended Posts

Hi...  I have a bit of an OOP design question.  The question basically comes down to this:  I have a table of users in a database.  I want to extract users based on user names, IDs, first name or whatever.  I already know I'm going to have a User object, but how should I go about creating/retrieving that user object?  (Perhaps I should dig more deeply into some ORM software...  Or just use a ORM library lol).

 

 

Let's pretend I have this:

 


class User {
    public function getFirstName() {
        //would return the first name
    }

    public function getUserId() {
        //blah
   }

    public function setFirstName() {
        //would set first name
    }

}

 

Simple enough.

 

But how would you go about populating the data in the user class?  If I were just doing object generating like:

 

$u = new User(1);

 

Or

 

$u = new User('Corbin');

 

That would be easy, but what if I want to do more criteria?  Like, how would I design something where I could search for users whose first name is Corbin and are over 20 years old?  What would the object layout of this be?

 

The more and more I think about this, the more I think I should use just use Propel or Doctrine.  Doctrine seems to have a few issues with MSSQL though....  (Stuck with MSSQL.)  Also, I think this is an interesting learning experience.

 

Obviously I need an object that does the work of extracting the users from the DB based on criteria...

 

For example:

 

$users = (new UserFilter())->equals('firstName', 'Corbin%')->greaterThan('age', 20)->getUsers();

 

Or something like that.  That would just build a SQL string, run it and so on.

 

That brings up another question though.  What's the best way to go about generating User objects from inside that?  Just passing an array of data to the User constructor?

 

Also, how should I pass around my database handle?  Obviously I want to avoid globals.  I also want to avoid a singleton, and passing the DB handle as an argument seems ghetto.  Should I have a factory or something, or is passing it the way to go?

 

 

 

Now to go read the OOP tutorials again and to look at Doctrine/Propel code :).

(Hopefully the tutorials don't cover this situation...  Otherwise I'm going to feel stupid ;p.)

Link to comment
Share on other sites

Corbin,

  I'd suggest taking a look at Zend Framework, which has solutions to a lot of your questions.  For example, ZF provides a configuration class, and a Registry class.  The config class will load up all your configuration specific variables, and the registry can be used to store connenctions, factories, and other singletons.

 

Use an ORM if the idea appeals to you.  Whether or not you use an ORM, you'll want to take a good hard look at MVC, if you haven't already.

Link to comment
Share on other sites

Hrmmm....  I'll definitely take a good look at the Zend stuff (by the way, I haven't looked at MVC as much as I should've by this point, but how is that involved?  I guess maybe just the design in a major MVC framework would help me understand?)

 

 

I think I'm going to go with registry for the database stuff, but I'm stuck on the user filtering...  I guess I need to google more ;p.

Link to comment
Share on other sites

If you want to keep it simple, mysql_fetch_object takes a class name as its second argument.

 

Example, providing you have a field named firstName.

 

class User
{
  public function getFirstName() {
    return $this->firstName;
  }
}

if ($result = mysql_query('SELECT firstName FROM users WHERE id = 1')) {
  if (mysql_num_rows($result)) {
    $user = mysql_fetch_object($result, 'User');
    echo $user->getFirstName();
  }
}

Link to comment
Share on other sites

Oooo thorpe, that's a good idea.  I'm plan on using MSSQL with PDO, but I see that the PDO fetchObject method has the same functionality.  Is like not like a OOP no-no though?

 

Seems kind of ghetto to just pass in all of the values.  Then again, I guess without doing a SELECT for every user object created (which would obviously be stupid if like 50 users were listed) that's got to happen somewhere.

 

By the way, gizmola, I read the ZF docs quite a bit the other night, and I think the design idea of the MVC design (or whatever you would call it) finally clicked (I used to not get how the three interacted together, just what each individually was supposed to do), but I didn't come across anything that was directly related to this.  I read most of the Zend_Db related stuff, and at one point it linked to an article talking about the active record pattern and rowset pattern and so on which kind of helped.  I guess basically I just need to realize that there's not a magical PHP wand that can be waved to make this entirely pretty.

 

 

 

For example:

 

$users = (new UserFilter())->equals('firstName', 'Corbin%')->greaterThan('age', 20)->getUsers();

 

You probably already know this, but that's not valid syntax.

 

Was just too lazy to break it into 2 lines.  Maybe some day :(.

Link to comment
Share on other sites

By the way, gizmola, I read the ZF docs quite a bit the other night, and I think the design idea of the MVC design (or whatever you would call it) finally clicked (I used to not get how the three interacted together, just what each individually was supposed to do), but I didn't come across anything that was directly related to this.  

 

 

Any chance you could post the link to that? I have been baffled by OO and MVC alike and have read numerous tutorials, articles etc. on the matter, still no luck...  :(

Link to comment
Share on other sites

Oooo thorpe, that's a good idea.  I'm plan on using MSSQL with PDO, but I see that the PDO fetchObject method has the same functionality.  Is like not like a OOP no-no though?

 

Seems kind of ghetto to just pass in all of the values.  Then again, I guess without doing a SELECT for every user object created (which would obviously be stupid if like 50 users were listed) that's got to happen somewhere.

 

By the way, gizmola, I read the ZF docs quite a bit the other night, and I think the design idea of the MVC design (or whatever you would call it) finally clicked (I used to not get how the three interacted together, just what each individually was supposed to do), but I didn't come across anything that was directly related to this.  I read most of the Zend_Db related stuff, and at one point it linked to an article talking about the active record pattern and rowset pattern and so on which kind of helped.  I guess basically I just need to realize that there's not a magical PHP wand that can be waved to make this entirely pretty.

 

 

 

For example:

 

$users = (new UserFilter())->equals('firstName', 'Corbin%')->greaterThan('age', 20)->getUsers();

 

You probably already know this, but that's not valid syntax.

 

Was just too lazy to break it into 2 lines.  Maybe some day :(.

 

Yeah, it's not really a magic wand, but just something that makes more sense when you just go ahead and try implementing it.  Usually when people start working on classes to model their approach to the business problem, those things end up going into the model layer. so that's what lead me to bring up MVC because it seems like you're moving in that direction and before long would be asking the types of questions about how to handle the flow of control and seperation of presentation from logic that MVC handles.

Link to comment
Share on other sites

Ahhh...  Yeah.  The more I learn about the MVC pattern, the more it makes sense to use it.  Hopefully my days of gluing some objects together with some hideous switch statements are soon gone lol.  (Although routing isn't with just MVC of course...  Definitely seems easier with MVC.)

 

I'm plan on using MSSQL with PDO

 

Good luck with that. I've had no end of trouble getting PDO working properly with MSSQL. You'll need to use the ODBC driver, which eliminates Zend from the picture for the moment.

 

Hrmmm....  Crap.  Didn't know that Zend_Db didn't have a ODBC driver.  I thought it basically had all the drivers that PDO does.  I guess if I use Zend (don't know if I'll even use a framework), I'll just use PDO in Zend.

Link to comment
Share on other sites

For interacting with MSSQL, take a look at ODBTP.  It works better than ODBC and even talks to FoxPro!

 

MS have there own extension for mssql now. Its by far the best I've used, but still, its not a PDO driver.

 

Ive not seen support for ODBTP in Zend either.

Link to comment
Share on other sites

For interacting with MSSQL, take a look at ODBTP.  It works better than ODBC and even talks to FoxPro!

 

Works better than ODBC?  Performance wise, less bugs, or what?

 

 

For interacting with MSSQL, take a look at ODBTP.  It works better than ODBC and even talks to FoxPro!

 

MS have there own extension for mssql now. Its by far the best I've used, but still, its not a PDO driver.

 

Ive not seen support for ODBTP in Zend either.

 

Yeah, I've used it before since I used to use the old php_mssql extension, then it technically stopped being supported with MSSQL 2000.  I used it for a while after that, but apparently it and 2005 don't get along.  As for the MS made one, I've used it a bit too, but I mainly just like PDO.  Too bad there's not a PDO driver that uses that.

 

Hrmmm...  I should probably check to make sure I won't run into any weird issues down the road with PDO_ODBC.  I'll have a few BLOB columns so I figure that will give me trouble if anything.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.