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.
And
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.
3
“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.
2
‘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).
2