Home/ Questions/Q 7796457
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-01T23:22:43+00:00

What good is a repository pattern when you have an ORM? Example. Suppose i

  • 0

What good is a repository pattern when you have an ORM?

Example. Suppose i have the following (fictional) tables:

Table: users

pk_user_id
fk_userrole_id
username

Table: userroles

fk_userrole_id
role

Now with an orm i could simply put this in a model file:

$user = ORM::load('users', $id);

Now $user is already my object, which could easily be lazy loaded:

(would be even nicer if things are automatically singular/pluralized)

foreach ( $user->userroles()->role as $role )
{
    echo $role;
}

Now with the Repository pattern i’d had to create a repository for the Users and one for the Roles. The repository also needs all kinds of functions to retrieve data for me and to store it. Plus it needs to work with Entity models. So i have to create all of those too.

To me that looks like alot of stuff do… When i could simply get the data like i described above with an ORM. And i could store it just as easy:

ORM::store($user);

In this case it would not only store the user object to the database, but also any changes i made to the ‘Roles’ object aswell. So no need for any extra work like you need with the repository pattern…

So my question basically is, why would i want to use a repository pattern with an ORM? I’ve seen tutorials where to use that pattern (like with Doctrine). But it really just doesn’t make any sense to me… Anyone any explanation for its use in combination with an ORM..??

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The ORM is an implementation detail of the Repository. The ORM just makes it easy to access the db tables in an OOP friendly way. That’s it.

    The repository abstract persistence access, whatever storage it is. That is its purpose. The fact that you’re using a db or xml files or an ORM doesn’t matter. The Repository allows the rest of the application to ignore persistence details. This way, you can easily test the app via mocking or stubbing and you can change storages if it’s needed. Today you might use MySql, tomorrow you’ll want to use NoSql or Cloud Storage. Do that with an ORM!

    Repositories deal with Domain/Business objects (from the app point of view), an ORM handles db objects. A business objects IS NOT a db object, first has behaviour, the second is a glorified DTO, it only holds data.

    Edit
    You might say that both repository and ORM abstract access to data, however the devil is in the details. The repository abstract the access to all storage concerns, while the ORM abstract access to a specific RDBMS

    In a nutshell, Repository and ORM’s have DIFFERENT purposes and as I’ve said above, the ORM is always an implementation detail of the repo.

    You can also check this post about more details about the repository pattern.

    • 0