passing the database-connection

[Remy]

I use some kind of controller-view-businessObjects framework that I developed by myself to learn from it. But with the goal the create the db-connection one time and pass it along so the smame connection is been used, I developed it rong. I create the db-connection in the controller which passes it through at the view, and the view passes it again through at the business object.

This is the wrong way obviously, because only the business objects use the connection. But how do I solve this?

The only thing I can think of is using objects in the view like the example below and not creating each time a new db-connection:

/* each business object as a method getDbConnection and
* can create a new db-connection if not givin.
*/
$article =& new Article(3); // creates a db-connection
// do somthing
$newsitem =& new NewsItem(4,$article->getDbConnection);
// do somthing 

I have been struggeling with this for a while, but I still don't get it how to do this right or if a even on the right path.

-Rémy

[Cam]

I don't really get what you mean

Are you trying to pass the DB connection by reference or do you not want to have to pass it at all?

[Remy]

Sorry, my question is not clear. I will explane it better.

First of all, I have the DB-connection removed from the controller en views, so that solved. The code looks like below at the moment (Controller and View are simplified for this post).

Controller.php:

<?php
/**
 * The Controller of the apllication
 *
 * Starts the correct view and performs the action that are requested.
 * @autor R&eacutemy van Duijkeren <[email=mail2remy@chello.nl]mail2remy@chello.nl[/email]>
 * @copyright 2003 R&eacuteMy Productions
 * $version 0.1
 * @package application
 */
Class Controller {
     /**
      * Containts a array of constants
      * @access private
      * @var array
      */
     var $constants;
     /**
      * Contains the template object
      * @access private
      * @var object
      */
     var $template;
    /**
     * Constructor of the application.
     *
     * Put all constants in a array, create the
     * templateObject and a DbConnectionObject
     * @access private
     */
    function Controller() {
        // get constants for the application and sets ini-settings
        include_once ("settings.php");
        $this->constants = array_merge($_POST, $_GET, $_FILES, $APPLICATION);
        ini_set("display_errors",$this->constants['display_errors']);
        ini_set("log_errors",$this->constants['log_errors']);
        ini_set("error_log",$this->constants['error_log']);
        ini_set("output_buffering",$this->constants['output_buffering']);
        // create TemplateObject
        include_once ($this->constants['pathUtility']."/Template.php");
        $this->template =& new Template;
        $this->template->setTemplateDir($this->constants['pathTemplate']);
    }
    /**
     * Starts the apllication frame work
     * @access public
     */
    function run() {
        if ($this->constants['online']) {
            $this->template->addVar("title","Homepage");
            $this->template->addVar("content", $this->excuteAction($this->constants['action']));
        } else {
            $this->template->addVar("title","under construction");
            $this->template->addVar("content", $this->template->parse("000underConstruction.tpl.htm"));
        }
        $this->template->display("Layout.tpl.htm");
    }
    /**
     * Execute the requested action
     * @param string $class The class name
     * @param string $method The method name
     * @access private
     * @return string all parsed HTML-code of the action or FALSE
     */
    function excuteAction($action) {
        // separate the action in class and method
        if (isset($this->constants['action'])){
            $class = strtok($this->constants['action'], '.');
            $method = strtok('');
        } else {
            $class = "Homepage";
            $method = "doDefault";
        }
        if (file_exists ($this->constants['pathApplication']."/".$this->constants['pathView']."/".$class.".php")) {
            include_once($this->constants['pathView']."/".$class.".php");
            $class =& new $class($this->constants, $this->db, $this->template);
            $result = (method_exists($class, $method)) ? $class->$method() : $this->pageNotFound() ;
        } else {
            $result = $this->pageNotFound();
        }
        return (isset($result)) ? $result : false;
    }
    /**
     * Shows a page-not-found page
     * @access private
     * $return string Contains all parsed HTML-code
     */
    function pageNotFound() {
        $this->template->addVar("title","404 Not Found");
        return $this->template->parse("404notFound.tpl.htm");
    }
}
?>

HomepageView.php:

<?php
include_once("View.php");
/**
* The Hompage view
*
* This class takes care of the view of the homepage.
 * @autor R&eacutemy van Duijkeren <[email=mail2remy@chello.nl]mail2remy@chello.nl[/email]>
 * @copyright 2003 R&eacuteMy Productions
 * $version 0.1
 * @package application
 */
Class HomepageView extends View {
    /**
     * Constructor of the view.
     *
     * Calls the constructer of the parent-class.
     * @access private
     */
    function HomepageView(&$constants, &$template) {
        $this->View($constants, $template);
    }
    /**
     * The default action
     * @access public
     */
    function doDefault() {
        // example of use of businessObjects!
        include_once($this->constants['pathBusinessObjects']."/Department.php");
        include_once($this->constants['pathBusinessObjects']."/Employee.php");
        if ( isset($_SERVER["LOGON_USER"]) ) {
            $Employee =& new Employee(substr($_SERVER["LOGON_USER"],-3));
        } else { Header("HTTP/1.0 401 Unauthorized");}
        $Department =& new Department($Employee->getDepartmentId(), $Employee->getDbConnection());
        $this->template->addVar("username", $Employee->getFirstName().$Employee->getLastName());
        $this->template->addVar("department", $Department->getName());
        $this->template->addVar("articletitel", $article->getTitel());
        $this->template->addVar("articlebody", $article->getBody());
        return $this->template->parse("userinfo.tpl.htm");
    }
}
?>

BusinessLogic.php:

<?php
/**
 * Business Logic Class
 *
 * The base class of which all businessObject should extend.
 * @author Rémy van Duijkeren
 * @version 0.5
 */
Class BusinessLogic {
    /**
     * Contains the database object (the DbConnection)
     * @access private
     * @var object
     */
    var $db;
    /**
     * Containts a array of constants
     * @access private
     * @var array
     */
    var $constants;
    /**
     * Constructor of all Business Objects.
     *
     * Put all constants in a array and create a DatabaseObject.
     * This should be called in each constructer class based on this class.
     * @access protected
     */
    function BusinessLogic() {
        // get constants
        include ("settings.php");
        $this->constants = $APPLICATION;
        // create DatabaseObject
        include_once ($this->constants['pathLibary']."/eclipse/MSDatabase.php");
        $this->db =& new MSDatabase($this->constants['dbName'], $this->constants['dbHost']) or die ($db->getErrorMessage());
        $this->db->connect($this->constants['dbUser'], $this->constants['dbPassword']) or die ($db->getErrorMessage());
    }
}
?>

Department.php:

<?php
include_once ("BusinessLogic.php");
/**
* Department Class
*
* @author Rémy van Duijkeren
* @version 0.5
*/
Class Department extends BusinessLogic {
    var $Id;
    var $Name;
    function Department($id) {
    $this->BusinessLogic();
        $result =& $this->db->query("SELECT * FROM department WHERE department_id = ".$id);
        if ($row =& $result->getRow(0)) {
            $this->Id = $row['department_id'];
            $this->Name = $row['name'];
            return true;
        } else {
            return false;
        }
    }
    function getId() {
        return $this->Id;
    }
    function getName() {
        return $this->Name;
    }
}
?>

Employee.php:

<?php
include_once ("BusinessLogic.php");
/**
* Employee Class
*
* @author Rémy van Duijkeren
* @version 0.5
*/
Class Employee extends BusinessLogic {
    
    var $Id;
    var $DepartmentId;
    var $FirstName;
    var $LastName;
    function Employee($id) {
        $this->BusinessLogic();
        $result =& $this->db->query("SELECT * FROM employee WHERE employee.employee_id = '".$id."'");
        if ($row =& $result->getRow(0)) {
            $this->Id = $row['employee_id'];
            $this->DepartmentId = $row['department_id'];
            $this->FirstName = $row['first_name'];
            $this->LastName = $row['last_name'];
            return true;
        } else {
            return false;
        }
}
    function getId() {
        return $this->Id;
    }
    function getDepartmentId() {
        return $this->DepartmentId;
    }
    function getFirstName() {
        return $this->FirstName;
    }
    function getLastName() {
        return $this->LastName;
    }
}
?>

The database is now only used by the businessObjects, but with each creation of a bussenissObject(Employee and Department) a new connection is been made to the database (if I am not wrong). I read some of the posts on this forum that are telling that this is bad, I should pass the dbconnection as reference.

The problem is how to do this the 'right way'? The only thing I can think of is put a extra method, getDbConnection(), in the class 'BusinessLogic' and change the constructor. The constructor should create a DbConnection if not given as parameter.

The change in the HomepageView should be something like this:

$Department =& new Department($Employee->getDepartmentId(), $Employee->getDbConnection()); 

Is this the 'right way'? Also if there are other thing I am not getting or doing wrong in my code, please criticise me, I am still new to OOP and want to learn the 'right way' to do OOP. images/smilies/smile.gif

-Rémy
(Why aren't enters display in PHPtag?)

[Captain Proton]

In your code above, your View (HomePageView) is still mangling with the database connection, by calling the method getDbConnection() on the employee object. There goes your layering

As for the question how to pass the database connection to business objects, I've been thinking about that question a lot too. Several options I could think of are:

• Initiating a database object in every business object.
  This is not a very nice solution, like you said. An application should require only one database connection, there is no need to initiate more.
• Using a Singleton
  By having your business objects access a DB::getInstance() method they get access to a database connection object. But this is similar to doing global $cfg and creates an unnecessary dependency (see my post in the 'best way to store settings' thread').
• Initiating the database connection somewhere else and passing it to all business objects that require it.
  This was the solution I chose to use. The database connection was initiated in the Controller and then passed to all business objects that needed it. No globals, no database connection for every business object

There are several things wrong with your MVC approach by the way. First of all, you instanciate your business objects (Model) in the View. A View should not have direct access to the Model, instead it should have access to it through the Controller. In practice that means that you should initiate the business objects inside the controller and pass them to the View. Second of all, your Controller contains logic that should be inside the View classes: it creates a template object.

Here's a (simplified) example of how I implemented the MVC pattern:

class Controller
{
    var $view;
    
    /**
    * Executes the requested action and chooses a View to display
    **/
    function execute()
    {
        $dbConnection = new DBConnection();
        $businessObject = new Employee($dbConnection);
        
        $this->view = new HomepageView($employee);
    }
    
    /**
    * Returns the chosen View, an object that will display the results
    * of the action
    **/    
    function getView()
    {
        return $this->view;
    }
}

class HomepageView
{
    var $employee;
    
    function HomepageView(&$employee)
    {
        $this->employee = $employee;
    }
    
    /**
    * Builds the View and sends output to the browser
    **/    
    function build()
    {
        // You could put this inside a template of course
        echo $this->employee->getFirstName() . ' ' . $this->employee->getLastName();
        echo $etc;
    }
} 

Another question you should think about: should business objects, objects that are concerned with the domain logic of your application, really be concerned with how to access their data, i.e. data access logic?

[Sork]

Heres how I do (try to) the MVC pattern and handle the db connections

the base Controller

class BaseController
{
    // DATA MEMBERS

    /***
    ***/
    var $mView;
    
    /***
    ***/
    var $mModule;

    // CREATORS

    /***
    ***/
    function BaseController(&$module)
    {
        $this->mModule =& $module;
    }

    // ACCESSORS

    /***
    ***/
    function getView()
    {
        $this->mView->getView();
    }
} 

an example

class UserController extends BaseController
{
    // CREATORS

    /***
    ***/
    function UserLoginController(&$module)
    {
        parent::BaseController($module);
    }

    // MANIPULATORS

    /***
    ***/
    function runLoginAction($args = array())
    {
        $model =& new UserLoginModel($this->mModule->getDatabase(),$thismModule->getHttpRequest());
        $model->setParam('userError',$args[0]);
        $this->mView =& new UserLoginView($this->mModel);
    }
} 

In the second layer (i guess ) I start the module and pass the db connection to him, the module will instanciate the right controller and passes the module object and the rest you can see.

Tell me what you think of this.

[Dr Livingston]

[Remy]

In your code above, your View (HomePageView) is still mangling with the database connection, by calling the method getDbConnection() on the employee object. There goes your layering

Your right, it shoudn't be in the View, but if it is in the Model, isn't this a other possible solution insteed of initiating the dbConnection in the Controller and then pass it to the Models\BusinessObjects. That way the Controller only is initiating Models and passes them to the Views.

There are several things wrong with your MVC approach... In practice that means that you should initiate the business objects inside the controller and pass them to the View.

Thanx for the comment on that. I let the Controller create the View, and the View creates the Model(s) it needs... so I should change that to: The Controller creates the Model(s) and creates the View with passing the Model(s) to it.

I will try to change it to that, but I see some problems. The Controller now needs to know which Model(s) a View needs.

$this->view = new HomepageView($employee, $department, $orSomeOther); 

This means I have to update\change the Controller often and it gets a lot bigger, if I'm right. (In mine approach the View creates the Models\businessObjects it needs, so the Controller doesn't have to know.) How you did solve this or am I seeing it wrong.

...your Controller contains logic that should be inside the View classes: it creates a template object.

Stupid of me, your right, it should be in the View .

should business objects, objects that are concerned with the domain logic of your application, really be concerned with how to access their data, i.e. data access logic?

Actually, I was already beginning to think of creating a new tier (data access logic) because the business objects are getting complicated.

Tell me what you think of this.

also . Taking a gues: You are start the application with initiating the model (with passing the dbConnection), which creates a Controller, which creates a View. What is the use of the Controller? I think nothing, so why use it?

[mkrz]

You might be interested in this link:

http://java.sun.com/blueprints/guide.../DEA2eTOC.html

The literature on Web-tier technology in the J2EE platform frequently uses the terms "Model 1" and "Model 2" without explanation. This terminology stems from early drafts of the JSP specification, which described two basic usage patterns for JSP pages. While the terms have disappeared from the specification document, they remain in common use. Model 1 and Model 2 simply refer to the absence or presence (respectively) of a controller servlet that dispatches requests from the client tier and selects views.A Model 1 architecture consists of a Web browser directly accessing Web-tier JSP pages. The JSP pages access Web-tier JavaBeans that represent the application model, and the next view to display (JSP page, servlet, HTML page, and so on) is determined either by hyperlinks selected in the source document or by request parameters. A Model 1 application control is decentralized, because the current page being displayed determines the next page to display. In addition, each JSP page or servlet processes its own inputs (parameters from GET or POST). In some Model 1 architectures, choosing the next page to display occurs in scriptlet code, but this usage is considered poor form. (See the design guideline Section 4.2.6.8 on page 89.)A Model 2 architecture introduces a controller servlet between the browser and the JSP pages or servlet content being delivered. The controller centralizes the logic for dispatching requests to the next view based on the request URL, input parameters, and application state. The controller also handles view selection, which decouples JSP pages and servlets from one another. Model 2 applications are easier to maintain and extend, because views do not refer to each other directly. The Model 2 controller servlet provides a single point of control for security and logging, and often encapsulates incoming data into a form usable by the back-end MVC model. For these reasons, the Model 2 architecture is recommended for most interactive applications.

The Front Controller architectural design pattern centralizes an application's request processing and view selection in a single component. Each type of Web client sends requests to and receives responses from a single URL, simplifying client development. The Front Controller receives requests from the client and dispatches them to the application model. This single point of dispatch makes the Front Controller a logical place for such global facilities as security and logging. The Front Controller also selects and formats the next client view. The controller is also an application of the Mediator pattern, because it decouples view components from one another.

[Captain Proton]

so I should change that to: The Controller creates the Model(s) and creates the View with passing the Model(s) to it.

Exactly. The fact that a Controller needs to know which Models a View needs to have is logical. There is a tight coupling between Views and Controllers, a Controller is used with one or more Views and knows what model data those Views need.

If you let the View create Model objects, you are in fact going back to the days of mangling all sorts of PHP code with HTML output, i.e. spaghetti scripts. The reason MVC is so useful is that it allows you to separate different concerns into different classes, i.e.:
- View: presents data from the model
- Controller: loads and manipulates the model

I will try to change it to that, but I see some problems. The Controller now needs to know which Model(s) a View needs.

In reality, how often is this going to happen? A Controller is used for one or maybe two Views, each of those Views has a specific purpose which (I think) is not going to change that often.

What is the use of the Controller? I think nothing, so why use it?

I can see why you'd say this. When you are simply loading up data from the database and displaying it, the Controller does very little as tier between the Model and the View. The real use of a Controller comes in when you have to manipulate the Model: i.e. add new model objects, update existing ones, delete, etc. For HTML views this is done with a <form> of course. There are more tasks involved now:
- displaying an edit form for the Model (View)
- validating form input (Controller)
- updating properties of the model, with setSomething() methods (Controller)
- choosing a View that informs the client of the success of his action (Controller)

As you can see, now it is useful to have a Controller.

Taking a gues: You are start the application with initiating the model (with passing the dbConnection), which creates a Controller, which creates a View.

Yeah, sort of. My Application class initiates a database connection and passes it to a Controller. The Controller creates a Model and creates a View, which accepts the Model as parameter. But as you can read in this post, I'm not completely happy with it either

[Sork]

You are start the application with initiating the model (with passing the dbConnection), which creates a Controller, which creates a View. What is the use of the Controller? I think nothing, so why use it?

Not model, but module. The module will instanciate the controllwer wich instanciate the model and the view.

NOTE: what you call aplication i call module.

Don't have much time to write more - work -, later

[Dr Livingston]

Just my thoughts....

The database is now only used by the businessObjects, but with each creation of a bussenissObject(Employee and Department) a new connection is been made to the database (if I am not wrong). I read some of the posts on this forum that are telling that this is bad, I should pass the dbconnection as reference.
The problem is how to do this the 'right way'? The only thing I can think of is put a extra method, getDbConnection(), in the class 'BusinessLogic' and change the constructor. The constructor should create a DbConnection if not given as parameter.

Yes, you should pass the database connection by reference; you should only really need to begin one (and only one) connection; from the business layer.

mkrz - this is a good link people. I visited a MVC page at Sun today and via some links, came across the TOC.

I've been trying to understand more about MVC and this did help me - a LOT

I'm well on my way now folks

Particular chapter 11...

Got to like those folks at Sun...

[Dr Livingston]

Via Captain Protons 'this post' link you may also want to read what HarryF and co have to say about events.... all at this thread:

http://www.sitepointforums.com/showt...4&pagenumber=1

Interesting reading I think ?

[mkrz]

I've been trying to understand more about MVC and this did help me - a LOT

Great. Same here. I think I got the link from one of Harry's posts, originally.

I'm not an expert on this, but I just had a look at the Eocene-Documentation (www.eocene.net). Really I think that more people should check this out (Please note that I'm not in any way affiliated to that site and am not even using the framework yet).

Anyway, in their Documentation you can see a nice diagram which shows the layout of their MVC framework. I found that they have a central FrontController. This FrontController has a method "DBConnect()". That is, the db connection is originally created in the FC and then passed to the model. The diagram actually says this:

FrontController has DBConnect (1-1). And then, in the model layer, it says: BusinessObjects uses DatabaseObjects. DataBaseObjects uses DBConnect. If you look at that diagram you will see what I mean. So, the database connection should not be created in the application logic layer, but in the FrontController, it seems to me.

[Dr Livingston]

For those of you who have yet to see the diagram from the Sun site then I've attached it as an image

mkrz - I'll be looking into this MVC framework you've being going on about

[Captain Proton]

See?, mvc isn't that hard

[Dr Livingston]

No; it's just difficult

[mkrz]

mkrz - I'll be looking into this MVC framework you've being going on about

Yeah, have a look at Phrame and Eocene. And then tell me what you like better and why. I think they are very similar, actually. If only one of them had a strong user base and everything.

[Dr Livingston]

Ummm.... I've looked breifly at both of them, though there isn't much to tell apart from them both IMO ?

I don't like however how phrame set's up it's actions - if I remember ? - using arrays ? This I think should be taken care of w/in a class - also the other framework I liked how it put all GET & POST data to a class - very convienent to find and read/write back data from one source.

So you do not need this for example:

$Id = (int) $_GET['id']; 

From what I read, I have the following based on their original:

/** dump $_GET and $_POST variables to class dynamically
 * version 01.1 by les quinn 13.05.03
 */
 class GetPostDump {
  var $keys = array();
  var $values = array();
 
  /** constructor
  */
  function GetPostDump() {
   # deal with $_GET first
   if($_GET) {
    while(list($key, $value) = each($_GET)) {
     $value = trim($value);
     $value = htmlspecialchars($value, ENT_QUOTES);
     $value = stripslashes($value);  
     
     $this -> keys[] = $key;
     $this -> values[] = $value;
    }
   }
   # deal with $_POST next
   if($_POST) {
    while(list($key, $value) = each($_POST)) {
     $value = trim($value);
     $value = htmlspecialchars($value, ENT_QUOTES);
     $value = stripslashes($value);  
     
     $this -> keys[] = $key;
     $this -> values[] = $value;
    }
   }
  }
  
  function PopGetPostVar($key) {
   $count = 0;
   foreach($this -> keys as $keys) {
    if($key == $keys) {
     # return value found belonging to given key
     return $this -> values[$count];
    }
    $count++;
   }
   # found nothing
   return false;
  }
  
  function PushGetPostVar($key, $value) {
   $count = 0;
   foreach($this -> keys as $keys) {
    if($key == $keys) {
     # put new value to a given key
     $this -> values[$count] = $value;
     
     return true;
    }
    $count++;
   }
   # key not found so create new one
   $this -> keys[$count] = $key;
   $this -> values[$count] = $value;
   
   return true;
  }
 }
.
.
# so I use following to read 'id'
.
.
$req = & new GetPostDump;
$Id = (int) $req -> PopGetPostVar('id');
.
. 

Which is now a lot easier and more portable correct ? At the end of the day, personaly I'd go for Eocene since I think it's more cleaner looking and easier to work with and to understand ?

But for ASP you'd have to wait I think since the ASP framework is still under construction...
[/PHP]

[mkrz]

Mmh, don't really understand your code example. I mean, what's it supposed to do? Doesn't Eocene include a predefined Request class that you can use to get request vars?

As far as I understand it, Phrame uses a configuration array for speed. Yesterday I discovered that they have a mailing list archive on sourceforge. Some people posted their modifications there, including an xml config file like in the original Struts (java).

I think the Eocene ASP version will never see the light of day, considering the current development speed in the PHP version.

[Dr Livingston]

Posted script - It's largely based on the Request class from Eocene.

Both frameworks are excellent choices I suppose at the end of the day, it's down to personal taste.

Although I think that Phrame would proberly need more time to study and use it over and above Eocene ?

Just my thoughts that's all

[mkrz]

Although I think that Phrame would proberly need more time to study and use it over and above Eocene ?

I agree. Phrame looks a bit harder to understand to me, too. Though I wouldn't say that this makes it less valuable. After all, it has Sessions and Form validation built in and can work with any presentation layer out of the box (PHP, Smarty, XSL, Flash). In this respect it has some advantages over Eocene.