Understanding the Repository Pattern

Lately I've been reading up on the repository pattern, but I'm just not understanding it.

Currently, using my own simple framework (MVC) I have models, within each model I describe the fields available and create the necessary methods to be able to interact with the database. Each model inherits methods from a base function to perform actions such as 'listAll', 'save' and 'getById'.

I have a database class which handles the connection to the database via PDO, and binding of parameters. It has methods such as 'InsertObject','updateObject' and 'deleteObject' which accept an object and either insert, update or delete it from the database. This class also has some query building methods which allow me to build simple queries without writing the SQL. For example, a method in a model might look like this;

public function getByActiveStatus($active = 0) {
$db = new \Db\DbPDO();
$results = $db->select()->from('users')->where('active=:active',$isActive)->bind()->getRows();

return $this->arrayToObjects('user',$results);

Open in new window

In my model, I might have other methods to manipulate the object. I suppose the class below isn't a great example as it is maybe best places in a helper class.

public function priceWithTax() {
$tax = (($this->price)  / 100) * $this->tax_rate;
return number_format($this->price + $tax,2);

Open in new window

Now my questions about the repository pattern.

1) My model, it would just contain parameters for the object. Can it still include extra methods like the priceWithTax() method shown above? or other methods that manipulate the object. What if I wanted a method to return a users firstname and lastname together, can I still put that in my model?

2) The repository class, can you/would you put SQL queries directly in there if you didn't use a database class/library? I'm guessing if you use a database class, all interaction with the db class would happen in the repository?

3) In most projects, isn't this overkill? as I guess it's very unlikely that the datasource will change? If it did change, in my case I would re-write the models to use a different database class. Even if using the repository pattern, if the datasource changes, you'd still have to re-write or replace the repository classes?
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Ray PaseurCommented:
1. Yes, anything that manipulates data belongs in the model.  Note that it does not want to be tightly coupled to the data source.

2. My feeling is that the DB might be a subset of the repository.  The repository could also include files, etc., whatever your application needed to persist its data.  A little more discussion here:

3. Now you're asking the important business questions!  Design patterns are supposed to work for us, not against us.  In some applications I've spent so much time making the application fit design patterns and abstraction layers, that I've actually added to the life-cycle cost -- it would have been easier to plan on a rewrite when the underlying needs changed.  You can overdo this stuff.  To the structural question here, I think "program to the interface" is good advice.  If you can express the interactions in terms of the application needs, you can create interfaces to the data model that reflect those needs.  Then when you have to change out the I/O subsystem (or similar) your interfaces and all the software/data that depend on them can survive, and only the lowest-level code has to be replaced.

If you're looking for some good hands-on, as well as theoretical learning, check into Laracasts.

HTH, ~Ray

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.