SitePoint Sponsor

User Tag List

Results 1 to 12 of 12
  1. #1
    SitePoint Wizard
    Join Date
    Feb 2009
    Posts
    1,006
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Help on solving - Login class on DAO relation.

    Hello all,

    Here's the thing:
    Scheme:
    I have a classDAO that extends abstractDAO and that abstract DAO requires on his constructor a myPDO singleton class.

    On each class DAO I can now successfully prepare statements and execute queries into the database;


    On this scheme I need to put a login class and here's what I'm thinking:

    On a given php file I will:
    1- Instantiate a DAOobject
    2- Instantiate a LoginObject

    This LoginObject will have a method called logIn;

    That logIn will accept three params (one optional): $user, $pass, $redirect = false;

    Since I don't need the DAO object on all the extension of the LoginObject,
    I'm thinking on doing a require_once of the DAO inside the logIn method. After that, I was thinking on doing the query that verifies is the $user and $pass are correct and if so, put them on a session and (if set, do the $redirect).

    Question:
    Before I spend long time into this. -
    Will we be able to query the database on our logIn method like we do on the other DAO classes, or that require will not properly work ?

    Any suggestion about a better way to integrate the login into the scheme mentioned above?


    Thanks a lot,
    Márcio

  2. #2
    SitePoint Wizard
    Join Date
    Feb 2009
    Posts
    1,006
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Something must be wrong with my question and I was unable to explain it properly perhaps? I'm sorry for that. :s

    If something is not clear, please let me know so that I can rephrase.

    I'm really clueless about the ways I can use to: interact the scheme (above) with a given login class ( that I would like to implement).



    K. Regards,
    Márcio

  3. #3
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,147
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    I would probably opt for something like:

    PHP Code:
    class DAOUser extends classDAO {

        public function 
    fetchUserByNameAndPassword($user,$password) {
            
            
    /*
            * Run SQL query to locate user and return data
            */
            
        
    }

    }

    class 
    DAOLogin extends classDAO {

        private
        
    $_daoUser;

        public function 
    __construct(DAOUser $daoUser) {
            
    $this->_daoUser $daoUser;
        }
        
        public function 
    loginUser($user,$password) {
            
            
    $user $this->_daoUser->fetchUserByNameAndPassword($user,$password);
            
            if(
    $user) {
                
                
    /*
                * Set session data etc
                */
            
            
    }
            
            return 
    $user?true:false;
            
        }


    The only code I hate more than my own is everyone else's.

  4. #4
    SitePoint Wizard
    Join Date
    Feb 2009
    Posts
    1,006
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hello, Sir Oddz

    On your example the classDAO will be the abstractClass correct?
    (On this case this abstractclassDAO is the one responsible for instantiate the myPDO singleton class, that allow us to connect)


    So, if we have:

    PHP Code:
    class DAOUser extends abstractClassDAO {

        public function 
    fetchUserByNameAndPassword($user,$password) {
            
            
    /*
            * Run SQL query to locate user and return data
            */
            
        
    }


    The question why I was reluctant about extending the abstractClassDAO on the Login class is that, the abstractClassDAO give us access the the connection methods (and probably other abstract things on the future), but on all DAOLogin class, the only method that seems to work with DAO is the Login method. I'm planning to have other methods such as "logOut" and "stillConnected" and those will rely on sessions and will never touch nothing about DAO I presume. Hence, I'm questioning if extension would be the right way for doing so.


    So, probably, instead of something like this:

    PHP Code:
    class DAOLogin extends abstractclassDAO {

        private
        
    $_daoUser;

        public function 
    __construct(DAOUser $daoUser) {
            
    $this->_daoUser $daoUser;
        }
        
        public function 
    loginUser($user,$password) {
            
            
    $user $this->_daoUser->fetchUserByNameAndPassword($user,$password);
            
            if(
    $user) {
                
                
    /*
                * Set session data etc
                */
            
            
    }
            
            return 
    $user?true:false;
            
        }


    I can have perhaps:

    PHP Code:
    class DAOLogin 
    {

        public function 
    __construct() {
        }
        
        public function 
    loginUser($user,$password$redirect false
        {
          
          require_once (
    'path/to/DAO.user.class.php');
          
          
    //NOT SURE WHEN WE SHOULD INSTANTIATE OR CALLED STATICALLY. :s 
          
    $userObj = new DAOuser;

          
    $user $userObj->fetchUserByNameAndPassword($user,$password);
            
          if(
    $user) {
                
                
    /*
                * Set session data etc
                */
            
            
    }
            
            return 
    $user?true:false;
            
        }

        public function 
    logOut() {
        
    //process the logOut
        
    }

        public function 
    verifiesLogin() 
        {
          
    //process to verify if the user is still logged in...
        
    }


    What do you think?

    Thanks a lot,
    Márcio

  5. #5
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,147
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by okriam
    The question why I was reluctant about extending the abstractClassDAO on the Login class is that, the abstractClassDAO give us access the the connection methods (and probably other abstract things on the future), but on all DAOLogin class, the only method that seems to work with DAO is the Login method. I'm planning to have other methods such as "logOut" and "stillConnected" and those will rely on sessions and will never touch nothing about DAO I presume. Hence, I'm questioning if extension would be the right way for doing so.
    Your working with data access objects. Either way your accessing data just data in different locations. I don't think its necessary to separate the data access out into different classes based on location of data. Besides if you ever need to use the database for login related operations the connection is there to use. Having access to the database adapter inside the login class doesn't really hurting anything.

    I generally favor composition over instantiating classes directly within other classes. That is why I proposed you create the user DAO outside the login class and pass into the login DAO upon instantiation. You will end up less tightly coupled code that way.

    However, for everything else your on right track. All login related data access operations would be placed inside the login DAO as you showed in your test code.
    The only code I hate more than my own is everyone else's.

  6. #6
    SitePoint Wizard
    Join Date
    Feb 2009
    Posts
    1,006
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    I generally favor composition over instantiating classes directly within other classes.
    I thought by doing so (instantiate directly inside other classes) I was doing composition. :s Capital interpretation error I presume.


    Quote Originally Posted by oddz View Post
    Your working with data access objects. Either way your accessing data just data in different locations.
    Not sure what you mean here about different locations...
    Can I read, on different classes?

    Quote Originally Posted by oddz View Post
    I don't think its necessary to separate the data access out into different classes based on location of data.
    Quote Originally Posted by oddz View Post
    Besides if you ever need to use the database for login related operations the connection is there to use. Having access to the database adapter inside the login class doesn't really hurting anything.
    Keep it short, you are telling that, it's not bad, because we can have the possibility for access them later, we never know, hence, why not extended instead of instantiate directly on the method?
    The only reason I can think of for not doing so it's that we can "waste resources" - what do I mean by this? In this sence: We are telling - extend all this class, but use always a bit of it.

    Should the question we should ask be:
    Are we sure that we never, ever, ever, will access our DAO outside that given method scope? If so, instantiate the class on that method.
    If not, do composition. ?


    You are telling me that I will probably access the DAO later, for perhaps, some login / database related issues.
    I'm telling you I don't know if I will have access to that DAO later.
    But probably I will. (please see last point).



    Quote Originally Posted by oddz View Post
    That is why I proposed you create the user DAO outside the login class and pass into the login DAO upon instantiation. You will end up less tightly coupled code that way.
    And that was my goal as well. Keep the user query on the DAOuser and not on the login class. And this was what lead me to the instantiation inside the class method.


    Quote Originally Posted by oddz View Post
    However, for everything else your on right track. All login related data access operations would be placed inside the login DAO as you showed in your test code.
    I cannot wait for finish this. It will be bad, but at least I can have something to start putting better.


    Last point:
    After your replies I end up thinking, I will have the same issue on a validation class. I mean, not all validation methods would have the need to access the DAO but one, the one that will verify if the user already exists uppon registration, that will use it.

    Perhaps there, I can use the benefit of having my login class connected to the data layer? Or not?

    I mean, mutatis mutantis, what relation would you suggest that we should have between our validation class and our login class ?

    Can we profit from the fact that our Login access the abstractDAO or, should we do the same we did with the login class - I mean, we will allow our validation class to extend our abstract data access object?


    Thanks a lot, and sorry for my always long threats. :s I'm trying my best for keep them concise as possible.
    K. Regards,
    Márcio

  7. #7
    SitePoint Wizard
    Join Date
    Feb 2009
    Posts
    1,006
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    For keep it short, we can reduce all that lettering to this:

    Let's assume a validation class will join the party:

    Not all validation methods would have the need to access the DAO but one, the one that will verify if the user already exists uppon registration, that will use it.



    Perhaps there, I can use the benefit of having my login class connected to the data layer? Or not?

    1)
    I mean, mutatis mutantis, what relation would you suggest that we should have between our validation class and our login class ?


    2)
    Can we profit from the fact that our Login access the abstractDAO ?

    OR

    3) should we do the same we did with the login class - I mean, we will allow our validation class to extend our abstract data access object?


    Much more clear I hope.
    Márcio

  8. #8
    SitePoint Wizard
    Join Date
    Feb 2009
    Posts
    1,006
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hello again,

    I was trying to apply it at this time but, if I use __construct() it will override the constructor that it's present on my extended class.

    PHP Code:
     public function __construct(DAOUser $daoUser) {

            
    $this->_daoUser $daoUser;

        } 
    Since I don't want to replace the construct instructions, I've changed to:
    PHP Code:
    public function DAOLogin(DAOUser $daoUser) {

            
    $this->_daoUser $daoUser;

        } 
    Is this the approach we should take to solve this?

  9. #9
    Twitter: @AnthonySterling silver trophy AnthonySterling's Avatar
    Join Date
    Apr 2008
    Location
    North-East, UK.
    Posts
    6,111
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Just call parent::__construct in your extending object's constructor.

    PHP Code:
    class Foo {
        public function 
    __construct(DAO $dao){
            
        }
    }

    class 
    Bar extends Foo{
        public function 
    __construct(DAO $dao){
            
    parent::__construct($dao);
        }

    @AnthonySterling: I'm a PHP developer, a consultant for oopnorth.com and the organiser of @phpne, a PHP User Group covering the North-East of England.

  10. #10
    SitePoint Wizard
    Join Date
    Feb 2009
    Posts
    1,006
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I do accept links or other sources but:

    Why is one better then another?


    Thanks in advance,
    Márcio

  11. #11
    Twitter: @AnthonySterling silver trophy AnthonySterling's Avatar
    Join Date
    Apr 2008
    Location
    North-East, UK.
    Posts
    6,111
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Sorry Márcio, I haven't read this thread.

    I noticed your issue surrounding the child class' constructor overriding the parent, so I offered up a solution to negate this.
    @AnthonySterling: I'm a PHP developer, a consultant for oopnorth.com and the organiser of @phpne, a PHP User Group covering the North-East of England.

  12. #12
    SitePoint Wizard
    Join Date
    Feb 2009
    Posts
    1,006
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm lost.

    Ok, so should we load the classDAO constructor:

    PHP Code:
    class DAOLogin extends classDAO {

        private 
    $_daoUser;

        public function 
    __construct(DAOUser $daoUser) {
           
    $this->_daoUser $daoUser;
        }


    Or putting a method with the same name as the class will suffice for NOT overriding the parent constructor?

    PHP Code:
    class DAOLogin extends classDAO {

        private 
    $_daoUser;

        public function 
    DAOLogin(DAOUser $daoUser) {
           
    $this->_daoUser $daoUser;
        }

    Or neither of those?


    Thanks a lot,
    Márcio


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •