Ever since I started working with iPhone and Core Data, ive been a bit taken back by how hap-hazardly the code ive seen is used for it. People just set up entity retrieval and fetches wherever it is needed in the code and move on. I believe i have an idea on how to fix this issue.
Here’s a quick summary on the repository pattern, explained by Martin Fowler:
A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to Repository for satisfaction. Objects can be added to and removed from the Repository, as they can from a simple collection of objects, and the mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes. Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer. Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers.
In a nutshell, all of the work for retrieving data from a data store is in one class. This is the idea behind it and how it would apply to Core Data:
As you can see, the data store would be Core Data (SQLite, or even just a large PList). The repository class in between would house all of the fetching, adding, removing, etc of that store.
I have created a project based off a default TableView project, and implemented this type of pattern into it. There should be a few things to note, which I will go over:
You will see a group called “CoreDataModels”, this is basically the models that Xcode automagically makes for you after you fill out your objects. I decided to rename it to “_Event” to make it a superclass and pull all the public methods in a subclass. This woud prevent Xcode from overwriting the files in the case I have to add/remove something from Core Data. Here is an illustration of what I am talking about:
You’ll notice that I have the addEvent and removeEvent in the subclass, and at its most simple form the only thing this function does is call the repository’s add or remove event call.
I have gotten this kind of habit from my .NET work, in which I use LinqToSQL, where it creates object models just like Core Data does. In those projects we did something similar mainly so that we can make changes to the database objects without having our custom code removed.
The second bit that I’ve done with this is created a RepositoryBase class that provides functions that are commonly used. Basic functions such as closing of the data store, and fetches are contained in this so that you’re not constantly re-writing the same fetch code over and over.
Lastly, I’ve created a singleton function so that no matter where you are in the app you can always call the same instance of the repository, which removes the possibilities of having disconnected data.
Working with this pattern really helps organize your data access layer, at the expense of having a few extra files. I believe the payoff though greatly outweighs the hit in file count.
And the source code for this project can be found here!
Next Steps:
I will be continuing to work on this, I plan on adding more functionality to make this a more robust and easy to use pattern. Stay Tuned!
Really great work. Thanks. I’ll be using this in my next project. Does it handle relationships and predicates?
have taken a good look through your code … your RootViewController still has fetchedResultsController property for retrieving the information about the model and in particular the managedObjects for the Event class. Should this responsibility not now lie with the Event class you created? Isn’t this the point?
You’re absolutely correct, i should have created a method that implements the repository call. I have updated the source code for this to work.
Thanks for the comments!
Looks like a great way to organize things! Thanks for sharing, I will be trying this out in my next project as well.
Great work James, I’m looking at using this pattern with SQLite. Have you done any more work on it lately?
I haven’t. Been really busy lately, im working on moving my examples to github, and adding in some other classes, such as custom font labels, and an API Communicator, for working with restful APIS.