Help on solving - Login class on DAO relation

PHP
1

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

I’m lost. :slight_smile:

Ok, so should we load the classDAO constructor:


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?

class DAOLogin extends classDAO {

    private $_daoUser;

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

Or neither of those?

Thanks a lot,
Márcio

3

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.

4

I do accept links or other sources but:

Why is one better then another?

Thanks in advance,
Márcio

5

Just call parent::__construct in your extending object’s constructor.


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

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

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.

 public function __construct(DAOUser $daoUser) {

        $this->_daoUser = $daoUser;

    }

Since I don’t want to replace the construct instructions, I’ve changed to:

public function DAOLogin(DAOUser $daoUser) {

        $this->_daoUser = $daoUser;

    }

Is this the approach we should take to solve this?

7

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?

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

  1. 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

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:


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:


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:


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

9

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.

10

I thought by doing so (instantiate directly inside other classes) I was doing composition. :s Capital interpretation error I presume.

Not sure what you mean here about different locations…
Can I read, on different classes?

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).

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.

I cannot wait for finish this. It will be bad, but at least I can have something to start putting better. :slight_smile:

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

11

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 [B]scheme /B with a given login class ( that I would like to implement).

K. Regards,
Márcio

12

I would probably opt for something like:


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;
		
	}

}