Last year I wrote three different articles. And I have to admit something…

I made a huge mistake

Repositories

After reading Fowler's "Patterns of Enterprise Application Architecture", I found that I royally messed things up. Repositories actually are in-memory collections or at least mediators to a different data store or subsystem that FEELS like an in-memory collection of records. Domain classes construct queries and then submit this query object to the Repository to grab data. So when we've been creating "Repositories" that take in simple parameters and return data sets, this doesn't really fit the bill.

UserRepository->findByEmail($email) doesn't really feel like working with a collection, nor does it work on local data, instead it only constructs queries. But is there a better fitting name for this?

Table Data Gateways

Gateways provide entries into discrete subsytems and provide a more logical API for the domain that wraps that subsystem. Table Data Gateways take in primative arguments and then return collection or row results from the database.

Take a look at Fowler's diagram of an example Table Data Gateway and see if it looks familiar?

find, findForCompany, update, insert

Martin Fowler P of EAA

TLDR;

Naming has impact. In the Laravel community, I have led people astray by teaching Table Data Gateways as Repositories. I'm still looking for an analog of the traditional Repository in terms of database interaction.

But if you are looking for a good Repository to look at, just read Laravel's source and the Illuminate\Config\Repository. It interfaces and adds nice query like sytax on top of the Laravel Config Loader which is relatively an existing in-memory collection to do work on.

So. You have be educated! Have a great time being able to speak the same programming terminology shared by everyone else!