This article appears to apply an additional level of indirection…I guess. Controllers are all the UIxxxControllers that control the view elements.
Views are what you mess with when you are in IB.
#Storyboard quick game controller code#
It seems like a mountain of code for such a small task. I am a beginning iOS developer and I am having a hard time following the logical flow of this program. I find this article to be extremely confusing. “You subclass UIViewController (or one of its subclasses) and add the custom code you need to implement your app’s behavior.” If it needs to do something a tad different with the data then let it.Īpple docs claim this as well. The viewController should be able to ask for the data it needs from the right places and then just display it in its views. Maybe I am wrong but this seems like it provides a ton of extra overhead to deal with when you should already have other classes designed for networking, model updates, storage or whatever you need. These would of course use a protocol or delegate to keep it decoupled from a specific model. Maybe you store it in SQL so you can have a SQL class that can accept your model. This can be your viewcontroller (or your viewcontroller controller you have) or it can be your networking code. The networking code should be completely decoupled from a model object entirely and models should just work with systems its handed off to. Maybe some stuff associated with serializing it but generally should be super simple. I would also like to mention that in my opinion a model should have almost 0 logic. So it’s more like a Model-View-Controller-Controller. I see the idea of removing the logic more for testing but this should be easily done if your models and your logic is done correctly without creating an extra controller. You are trying to remove the controller from this but you kept the same naming conventions. I always got the impression Apple likes to combine the view and the controller. Hmm this is interesting and I see what you are trying to do but I feel like this way just makes it more confusing to understand, follow and even debug. YacktmanĪpplication Architecture Fundamentals - Bob Tabor. Here are some great resources to help dive into MVC, Separation of Concerns, Architecture and more!Ĭocoa Design Patterns - Erik M. Changes that happen in the model are also sent from the Controller to the View. Users interacting with elements in the view result in requests made to classes(objects) in the Controller layer, which in turn may request changes to information in the Model. They contain the Buttons, Text boxes, WebViews, etc.Ĭontroller - The purpose of the classes in this layer is to decouple the Model from the Views.
are the part of the application the user interacts with. View - The elements in this layer, whether they be classes, story boards, xibs, etc. It should be able to stand alone with out dependencies on the View or Controller layers. The Model is the layer that makes the application valuable. One set of classes may contain network communication logic. One set of classes may contain data persistence logic. One set of classes may contain calculation logic. Model - The classes in this layer contain the special “business logic” and address the problem domain that the app is all about. Some notes that might help in the description of MVC.
0 kommentar(er)
