Tim Fletcher

Thanks Corbin. With regard to accidentally connecting to the database twice, the database class I'm creating is actually a singleton and so I can try to create it as many times as I like and still only have the single instance. I left it out of this example for brevity. I appreciate that you might not use the actual database connection and therefore there's no point in creating it until you actually need it. I just can't quite see that you'd create a database object if you actually didn't intend on using it. I mean databases and web apps are virtually one and the same! Maybe my limited experience is showing a bit on this one. Is the overhead of connecting that significant? Maybe I could write some kind of test. Oh, and thanks for the streamlined code. Cheers!

Hi, If you're creating a database abstraction class, is there any reason not to connect to the database in the constructor? I continually see examples of methods (like query($sql)) within the abstraction class checking to see if there's a database connection and creating it if it doesn't exist before they continue. Putting the connection into the constructor means you never need to check for the connection because if it wasn't there the object wouldn't have been instantiated from the class in the first place. I was wondering if there's some reason not to connect to the database until the very second you need it. So basically this: class Database { protected $db; public $dbname; public $host; public $user; public $password; public function __construct($host, $user, $password, $dbname) { $this->host = $host; $this->user = $user; $this->password = $password; $this->dbname = $dbname; $this->db = $this->connect(); // Any reason not to do this here? } public function connect() { $this->db = new mysqli($this->host, $this->user, $this->password, $this->dbname); return $this->db; } } Instead of this: class Database { protected $db; public $dbname; public $host; public $user; public $password; public function __construct($host, $user, $password, $dbname) { $this->host = $host; $this->user = $user; $this->password = $password; $this->dbname = $dbname; $this->db; } public function connect() { $this->db = new mysqli($this->host, $this->user, $this->password, $this->dbname); return $this->db; } public function query($sql) { // Connect to database if not already connected if( ! is_resource($this->db)) $this->connect(); // Rest of method.... } } Thanks!

Thanks for your answer aschk. So if I understand correctly - in this instance the purpose of making the front controller a singleton is to ensure its availability throughout the application AND to ensure that each time you access the object it is same object. If you needed access, you would simple 're-instantiate' the object using the FrontController::getInstance() method which would return either a new object (first time) or a reference (subsequent times). That sounds reasonable enough to me. Thanks!

Firstly, sorry for bringing this post back up. Maybe I should have started a new topic but I felt my comments were most relevant in this thread. I'll repost if necessary. I'm a little confused as to why it is useful to have the Front Controller implemented as a singleton. Surely as a 'core' class and one of the first pieces of code to be executed it would be impossible to have a situation where you could instantiate it more than once. There wold be absolutely no need. I understand that in the case of a database class you might need to use a singleton to ensure only one database object but what does it achieve here? Is it merely good coding practice to use a singleton if you know you only need a single instance regardless of the situation? Thanks!