Difference between Data Access Layer and Model in MVC

Question

I have implemented what I thought was a pretty decent representation of MVC in several web applications but since having joined crackoverflow, I'm finding that perhaps my initial definitions were a bit simplistic and thus I'd really like some clarification on the differences between the Data Access Layer and the Model or Domain Layer of a web application.

For context, I currently use data access objects that implement the CRUD functions for a single record in the table that the object represents as well as a get() function that returns an object that allows me to iterate through all of the objects that met the criteria for the get() function.

These data access objects are referenced directly from the controller scripts which contain my business logic.

If it matters, I'm working in PHP and MySQL but am interested in suggestions that might be coded in other languages.

UPDATE: For a more specific example, I have table called user (the convention here is singular table names) which holds such information as email address, active state, user name, password, which company they belong to, etc. This basic object would look like this in code:

class User implements DataAccessObject
{
     protected $user_id;
     protected $email;
     protected $username;
     protected $password;
     protected $company_id;
     protected $active // Bool that holds either a 0 or 1

     public function __construct ( $user_id ) // Uses Primary Key to know which record to construct
     {
          $sql = //Sql to get this information from the database.

          // Code necessary to assign member variables their values from the query.
     }

     public function insert(){}
     public function update(){}
     public function delete(){}
     public static function get($filters, $orderVals, $limit){}

     // An object such as user might also contain the following function definition
     public static function login($username, $password){}
}

It sounds like I might have bastardized the DAO Layer and Model layer into a simplified form that combines both any real-world type functions (such as login for a user) with the data access functions.

Answer 1

The model classes stand alone as a good, clean, high-fidelity model of real-world entities. If it's a business domain, they might be customers, plans, products, payments, all that kind of stuff. Your application works with these classes. The idea is that your application is a model of real-world handling of the domain objects. Your application can have method functions that look like verbs people really do, and the implementation of those method functions looks like a real-world description of real-world objects.

Important: This is (ideally) independent of most technical considerations. It's the purest model of the domain objects you can define. [Yes, you do have foreign-key lookup issues, and yes, you do have to make your model objects aware of some data access components so that a model object can find each other objects given just foreign keys instead of the actual object. A good ORM layer handles this navigation issue for you.]

A model full of SQL isn't a good model. The real world isn't full of SQL, either. An invoice is a document with some names and addresses and items, and a shipping date, and a bunch of stuff like that.

The access classes handles persistent storage. This usually includes mapping your model objects to relational database tables. A SQL-oriented data access layer would reconstruct your model from a relational database and persist your model in a relational database. A YAML data access layer would read and write YAML files from your model.

Sometimes, the object-relational mapping (ORM) design pattern is used to make a clean separation between SQL's world and your model. Sometimes a Data Access Object (DAO) handles this separation between SQL and model. A ORM or DAO object can be packed full of SQL.

Indeed, when you change database products, the only change is in the DAO or ORM. The model never changes, because it is independent of SQL, YAML, JSON, XML or some other serialization technique.

If your DAO creates and persists model objects, I think you've got the model parts of MVC implemented reasonably well. You can look at ORM packages to get additional ideas of the state of the art. I'm a fan of iBatis, myself.

But's only 1/3 of the whole MVC world-view. And -- of course -- purists will tell you that MVC is only desktop or only smalltalk or different from the common web implementation of MVC.

Answer 2

It's just a matter of higher abstraction. If you think about some business problem you are about to solve, you want to think about it in terms of concepts (entities, relationships, processes, etc.) of that business, not in terms of database objects or on more detailed level, in terms of internals of some specific database system (eg. MySQL). This way, you can model the domain (ie. the business and its rules) independently on the particular technology you use for implementation.

In other words, when you talk "data-access-layerish" you talk about tables, rows, data types, or even about approaches to access these data (eg. by using Active record pattern) while when you talk about about domain, you talk about business objects, business rules and business processes.

And, by the way, when using MVC pattern, you should encapsulate the business logic in your model (domain) level (as I said above), not in controllers - they should just trigger those rules, so to say.