I recently decided to start learning iOS Development, and to this end I’ve been reading iOS Programming: The Big Nerd Ranch Guide. In the book the authors describe a design pattern MVCS - Model-View-Controller-Store, the basic idea being that since many applications make use of multiple external sources of data keeping the request logic in the controller can get very messy, instead the authors propose that moving all the request logic out of the controller and into a separate object.

In short to quote the book

Model-View-Controller-Store puts request logic into a separate object, and we call this object a store (Figure 28.4). Using a store object minimizes redundant code and simplifies the code that fetches and saves data. Most importantly, it moves the logic for dealing with an external source into a tidy class with a clear and focused goal. This makes code easier to understand, which makes it easier to maintain and debug, as well as share with other programmers on your team.


The cool thing about asynchronous stores is that even though a lot of objects are doing a lot of work to process a request, the flow of the request and its response are in one place in the controller. This gives us the benefit of code that’s easy to read and also easy to modify.

I wanted to find out more about this pattern and to see what others might have to say about it, but while searching online the only references I could find were to that same book (is the pattern perhaps known by some other name?).

To me the author’s logic seems to make sense, and it seems like a logical extension of the regular MVC pattern, but perhaps that's because I don’t really have much experience with the MVC pattern in practice (aside from foray into iOS development I have sort of used MVV with backbone.js (that is, if you consider it MVC)).

I was hoping that perhaps someone with more experience can shed some light on whether there are any obvious flaws/problems with the MVCS pattern that I’m missing.

  • 2
    RobotLegs in ActionScript uses the "S" in MVCS to mean service. But it's used essentially the same way. So there's at least one other example of it. Commented Jan 22, 2013 at 2:25
  • 1
    In MVC, the Store is usually part of the Model. It's called the DAO part of it. Commented Jan 22, 2013 at 7:53
  • @FlorianMargaine are using as opposed to the Controller (which seems to be implied from this book (it says "In MVC request logic is the responsibility of the controller objects")? And do you see any obvious downside to moving it into its own layer?
    – Jack
    Commented Jan 22, 2013 at 16:50

2 Answers 2


"Store", in the case of MVCS design patterns, tends to lean towards storage logic. In the case of iOS, this is usually a Core Data implementation. If you create a Core Data-backed template in Xcode, you'll see the "Store" aspect of this design pattern tucked away in the AppDelegate class.

To take this to the next level, I will often create a singleton manager class that handles setting up the Core Data stack, and deals with all of the fetching/saving that is involved with the stack. As the quote you mentioned says, this makes it very easy to not only call those methods, but to adjust them if needed, as opposed to having saving/fetching calls all over the place in different view controllers.

The "Store" paradigm isn't restricted to Core Data, though. Your store may just be a web service. Perhaps you have a class that interacts with Facebook, Twitter, Yelp, or some other REST-based API. I have found (and similarly follow the trend) that these kinds of classes also have are named Manager. They are very literally managing all of the internal details so that your other classes can just put in or get out exactly what they need.

As far as obvious flaws or problems with this design pattern...As with any design pattern, the most glaring problem is ensuring that you've set up your project in such a way that jives with the paradigm. Especially with a design pattern that is new to you, this can sometimes be the hardest part. The benefit of breaking your "Store" logic out into its own class is the very fact that it makes code maintainability much easier.

  • Thanks for the insight, this actually similar to the approach that I started taking, in that I have a singleton manager class that deals with the core data stack and a Web API.
    – Jack
    Commented Jan 22, 2013 at 16:41
  • Hello @jimstone , I'm bit confused regarding the Store logic. Can you please help? Suppose I have 5 models, for each I have 2 classes, one which maintains networking and other caching of objects(Core data and stuff). Now should I have separate Store class for each model which call function containing networking + cache function calls or a single Store class which has all networking + cache function calls for each model, so the controller always access single file for data.
    – meteors
    Commented Aug 14, 2015 at 18:37

'Store' in this context sounds very much like a Repository or Service. In that case, this is an extremely common pattern. The flaws/problems will vary with your implementation and the problem domain.

On a general level, it sounds like the book is using 'Store' to represent a level of business logic + a level of data retrieval logic that handles a set of data that may or may not be part of your application.

For instance, wrapping the twitter api in a 'Store' is a nice way to compartmentalize that logic.

Upon further thought
Using this definition of MVC (which I think is pretty spot on), the 'Store' is really a subset of the model. The delineation between whether it's an extension to MVC or whether it's a data retrieval pattern isn't terribly useful. They end up looking like the same code.

Bottom line, I think you'll be fine following the advice they suggest (seems sound overall).

  • 1
    Reading through the links you provided It does sound similar, except here its being used as an extension to the MVC pattern.
    – Jack
    Commented Jan 22, 2013 at 16:45
  • 5
    +1, it sounds like they've just come up with a new name for the repository pattern (a repository being one kind of service).
    – MattDavey
    Commented Jan 22, 2013 at 18:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.