Setting up a repository pattern in MVC

Question

I'm trying to figure out how the Repository pattern works and how it can be implemented in a custom MVC pattern.

As far as i understand it, the Repository is a layer which simply returns data from an entity class or saves the entity class to a persistent layer.

Now i currently see it like this:

A request comes in into my controller to create a user. Just a username and password. My controller will do something like this:

function CreateAction ( )
{
    $userRepo = new userRepository ( );
    $user = new userEntity ( );

    $user->setUsername('user');
    $user->setPassword('123456');

    $userRepo->create($user);
}

Then my userRepository class looks like this:

class userRepository
{
    public function create ( User $user )
    {
        $this->db->exec ( "INSERT INTO ... QUERY TO SAVE THE USER" );
    }
}

And my userEntity class looks like this:

class userEntity
{
    private $username;
    private $password;

    public function setUsername ( $username )
    {
        $this->username = $username;
    }

    public function getUsername ( )
    {
        return $this->username;
    }

    public function setPassword ( $password )
    {
        $this->password = $password;
    }

    public function getPassword ( )
    {
        return $this->password;
    }
}

Now the first thing that i think is wrong here is that i'm using a query inside the repository class. Where do i actually save the userEntity class to the database? So in other words, where do i perform the actual SQL queries? I guess the proper way would be to call a DAO inside the 'create' method of the repository. But i'm still trying to figure out how a DAO really looks and how different it is compared to a 'Model' in terms of the Model in a MVC pattern.

But other than that, is this the proper way of implementing the repository pattern??

Heteromorphic

Looks pretty good to me. The repository is the correct place for sql. Might want to take a look at the Doctrine2 ORM manual just for ideas. – Paniculate

Answer 1

Your Repository looks much more like a TableDataGateway to me. The idea of a Repository is to be another layer on top of the mapping layer that mediates between the domain objects and the database. It also serves as an in-memory storage of domain objects (something that is missing from your example) and may encapsulate a Factory for creating new Entities. They often also allow for querying the Repository by Specification patterns:

It's a rather complex pattern. You can find good write-ups about Repository in

• Fowler: Patterns of Enterprise Application Architecture
• Evans: Domain Driven Design
• http://thinkddd.com/assets/2/Domain_Driven_Design_-_Step_by_Step.pdf

Also check Good Domain Driven Design samples

Mossgrown

Answer 2

Yes, this is a correct implementation of the Repository pattern. The DAO pattern is often useful as well, but there's nothing wrong with your implementation.

DAO is simple a pattern that separates your persistence logic from your business logic. It would create CRUD operations while your entity would contain methods for your business logic, so it's separating the responsibilites of persistance from your domain. I usually go for DAO for single entities and repositories for aggregates, allowing me to do things like productCatalogRepository.Update(), which in turn will iterate over the product DAOs and have them store themselves.

Shoelace