ios networking code in the model?

I recently watched the 'Network Apps for the iPhone OS' videos for WWDC 2010 in iTunes U and the speaker said that the best place to write your networking code is in the model. This kind of confused me because I have always placed this code in the controller classes. Can someone please explain why this is the best place for the networking code? Also if possible please 开发者_StackOverflow中文版provide an example, code or pseudocode, either works.

---

I wonder if we're all using the same terminology? Here's what I would use and I think (though I'm saying this without much context) what the WWDC presenter meant:

• Model. The data
• View. What it looks like in the UI
• Controller. The layer than mediates between the Model and the View

Using these definitions, the controller is a terrible place to keep any networking code. It has nothing to do with the interaction between the UI and the data.

Of course there's no reason why you couldn't have multiple classes for your model: one for the data representation and another to mediate between your web service and your data model. In this sense it would be a controller but would, nevertheless, be in the model layer of the application.

---

I think the model is an extremely terrible place to implement any kind of networking code. Since networked operations should proceed in an asynchronous fashion, a controller object is best suited to handle the complexities related to firing off requests and handling the response. It does make sense for a model object to know how to construct itself from downloaded data (XML or JSON, for instance), but most of the services code I've seen in model objects is poorly-written, synchronous networking.

---

Hmmm... that does seem to be a fairly odd remark, but then again, maybe it's valid in some contexts. Certainly, I know my models end up having a lot of networking code in them;

That is, the Model should handle everything having to do with the data and accessing it. That necessarily means that the Model will include the code to connect to whatever the backing store is for the data.

Parts of the Model might not have networking code in them at all, if the data is local. But consider that networking code is used to transfer data from somewhere to somewhere else; If you are coding based on Models first, it will probably follow that pretty much all of your networking code will end up there.

---

What is call Model in this post is in fact the Domain Layer and not the data container used between controllers and views

Network operation are generally asynchronous and your model is most likely to be present to handle response while you controller could have been destroyed by your navigation between the request and the response. That could crash your application because the delegate (the controller in your case) is no more present in memory and at least create memory leak because the delegate is generally responsible to release the connection object.

---

The "networking is best done in the model" is as you say explicitly mentioned by Apple's networking guru Quinn The Eskimo during the WWDC 2010 session. Having recently completed two fairly major apps with comprehensive networking, I am very keen to try something different on my next project, in line with Apple recommendations.

However, it's a strange thing that in general you can find tons of resources on iOS development, but with this I have really struggled to find any information. That is, searching on iOS networking architecture, and networking in the model, and so on. That was until I recently posted a similar question on Apple's dev forums. Quinn provided a very helpful response. You can read it here: LinkedImageFetcher and Network Code in the Model

Quinn pointed out that the best sample to demonstrate this is MVCNetworking

Also, that despite not having had the time to update the sample with Core Data, NSURLSession, and so on, he still feels that "the basic architecture of MVCNetworking is fairly sound."

Finally, this post was also referenced; looks like it has some really great links:

MVCNetworking on iOS 5

---

Networking, parsing, ecc...surely go in the Model part of an app...For model i mean the part of the MVC pattern not strictly on the model representation object.

I'll think to build a structure like so:

When the controller ask for some data to the model, it has a dependency to a kind of Network Manager, now the only think model have to do is invoke a method in it (specified in a protocol) and wait for the response (obviously async). The Network Manager has a reference to a specified class that is responsible to make the network call and return a raw data, when a completion block is fired the Network Manager gives that data to a Parser object (obviously with a method specified in a protocol), wait for the response and when the data is retrieved and parsed returns the array, dictionary or what you need to the model with the new data updated in it, after all this can pass back to the controller to make a reloadData or something like so and update views with updated data.

I hope would be helpful.