What do you think about adding a layer with logic between the Models and View Controllers in the MVC pattern?
We have models for REST resources that consist of readonly properties and methods for updating/fetching data on server. These models are placed in a framework that is used by multiple iOS / OS X apps, so we don’t want to add any app specific code to them.
The view controllers access these REST resource models through a layer where frequently used logic are placed, for example filtering and cacheing large collections. The layer consists of classes where each class corresponds to a REST resource and each instance of the class has an instance of a REST resource model. The REST resource is public so the resource and its values can be read directly by view controllers.
What should the classes in this layer be called? Are they controllers, helpers, perhaps utils or something else? Or is this an invalid Cocoa design pattern?
For example, if the resource is named “Activity” could its class be named “ActivityController”?
From my understanding, it seems that what you are using is generally speaking a Wrapper on a resource model. More specifically given that you are placing filtering logic inside it, maybe Proxy is the correct name. I don't think that this is an invalid Cocoa design pattern. Anyway
The REST resource is public so the resource and its values can be read directly by view controllers.
sounds odd. The resource should be private and the proxy should provide functions to access to model's values.