Model in MVC is the DAO class?

I’ve been following Harry F’s guide pretty closely regarding the DAO class. He connects it to the MVC pattern, letting the model class take data from the DAO classes. However, can I just combine model and DAO classes together? Is there a reason that there is the model class?

All my model classes look like this

class model {

  var $dao;
  var $result; // where database results will be stored

  function model(&$dao) {
    $this->dao =& $dao;
  }

  function getUsers() {
    $this->result =& $this->dao->getUsers();
  }

  function getPosts() {
    $this->result =& $this->dao->getPosts();
  }

  // and so on...
}

Each corresponding method just calls the dao method (same name), and passes the same parameters, in the same order, to that dao method. The dao does the sanitation and considerations (if statements) to create the query, then executes it. In fact so far I’ve been taking care of everything on the DAO level.

I want to get rid of the model layer here, and just let the DAO itself carry all the results instead of returning them. Can anyone tell me why I shouldn’t? Is there an OOP principle that balances out the return, so that it stays away from the God class smell?

However, can I just combine model and DAO classes together?

One important point of a DAO is that it is reusable and you can take it with you. Not sure exactly how’d you combine a Model and a DAO in respect of what you want to do but I think it’d be a bad idea :slight_smile:

Also, the DAO sits below a Model in layering terms, so what happens later you want to use another method of storage or a different database? What your proposing is that the Model and DAO should be on the same layer yes…

I’ve just been using the same tutorial for DAO’s and found the same thing. I made the database specific class and parent DAO then had another layer of domain specific DAOs as children, when I was building my controller I only had to use a few lines of code to get my data for each action using the child DAOs. Its probably wrong, I guess if it made you feel better about it you could take the letters ‘DAO’ out of the name of the child classes and replace with ‘Model’ :wink:

Also, the DAO sits below a Model in layering terms, so what happens later you want to use another method of storage or a different database? What your proposing is that the Model and DAO should be on the same layer yes…

Exactly.

I prefer to have a set of Finder classes for a specific model.

For example:


$articles = &new ArticlesController($dao);
$articles->finder->findByName($_GET['name']);
$article = $articles->finder->fetch();
$view = &new ArticleView($article);
echo $view->render();

So you basically set up a helper object (a finder) that serves as an interface between your model and the data source.

DAO can be ambiguous. Some people consider the DAO to be what fowler calls a mapper. This is how it is often used in J2EE apps.
Others call their (reusable) data access layer the DAO, which sounds like what you are thinking of.
And others combine the business object with the mapper/DAO(first definition) and call this business object a DAO since it has data-access as part of its functionailty

If using more than one database within a single application, often your data access layer contains an interface, which is implemented for different databases. In which case the business object just gets the results from the appropriate data access object for the required database, which essentially makes some methods into facades. I think this is what is happening in the example posted.

People generally go one of two ways:

  1. generic data access class that is re-usable among applications
  2. interface data access class which contains application specific database calls that must be implemented by the database specific data access class.

Maybe it is possible to use these in conjunction, but then again, that might just add one too many layers and turn into an over-layered architecture…

You would still need your insert/update methods to have an interface between the model and the data source in that case too.

Well, then I seem to be mistaken with what you mean by interface in this case…

Highly recommended book which will really help you get to grips with all this stuff is Patterns of Enterprise Application Architecture. The pattern catalogue contains brief descriptions which are explained more fully in the book. Check out the Data Source Architectural Patterns.

I’d second McGruff’s recommendation and suggest that in your case you take a look at: Table Data Gateway (Data Mapper would also be of interest).

Looking at your original example, it really doesn’t make sense to have your Model class just be an identical facade over your DAO class. An object using either of them could not tell the difference, so just use the DAO if you like that style.

The reason you would want a Model object is if it did some additional stuff, such as calculations or checking state, that were beyond you basic data/gateway object.

Well, you use the interface, but the objects that implement the interface define the getting of info from the specific database.
So if u want to switch between databases, that is the way to go

Yes, which is why you would have it call the data object to get the appropriate data base results and use logic on that

Well, you use the interface, but the objects that implement the interface define the getting of info from the specific database.
So if u want to switch between databases, that is the way to go
Although you might do that on a DB Connection layer below the DAO if you wanted portability.

Not really.
In that case, if you had a query that was a stored proceedure in MS SQL, you would be required to have a stored proceedure in MySql with the same named paramters.
Using the other method, you would implement it as you like as long as the method returned the same results.

Any Code Samples would be really nice, guys. :slight_smile: