Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
1  
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. –  Amy Blankenship Jan 22 '13 at 2:25
    
In MVC, the Store is usually part of the Model. It's called the DAO part of it. –  Florian Margaine Jan 22 '13 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 Jan 22 '13 at 16:50
add comment

2 Answers

up vote 8 down vote accepted

"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.

share|improve this answer
    
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 Jan 22 '13 at 16:41
    
Well it is definitely helpful, I wanted to leave the question open for a bit longer to see if any one had anything to say on the subject. I also wanted to read up a little more on some of the references others have posted. (I'm used to posting on SO where it is a bit easier to see when a question has been "answered", however if you take a look at my account you'll see that I have a pretty good accept rate there). –  Jack Jan 23 '13 at 1:43
add comment

'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).

share|improve this answer
    
Reading through the links you provided It does sound similar, except here its being used as an extension to the MVC pattern. –  Jack Jan 22 '13 at 16:45
3  
+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 Jan 22 '13 at 18:00
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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