MVC Pattern – Why Use MVC Design Pattern?

Using your example the Controller would be what decided what was a legal move or not. The Controller would let the view know how to arrange the pieces on the board at start up using the information it received from the Model. There are more things that can be handled by the Controller but the key is to think about Business Logic on that layer.

There are times when all the Controller does is pass information back and forth, like a sign up page. Other times the Controller is the difficult part of the development because there are many things that need to be done at that layer like enforcing rules or doing complicated math for example. Don't forget the Controller!

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