• MVC, MVVM,
    • Five essential aspects
      • Separation of concern
      • State sharing
      • State propagation
      • View controller communication
      • Parallelism
    • Aim of architecture
      • Fix the massive-view-controller issue
      • Increase testability
      • Improve maintainability
      • Scale with team size
    • MVVM
      • The purpose of this pattern is separation between the user interface from development and business logic development and facilitate testing
      • Model
        • It is a domain model
        • Includes data, business logic and validation logic
        • Does not depend on other components (view and Viewmodel)
      • View
        • Determines the structure, location and appearance of the user interface (as with Apple MVC)
        • Has view’s logic: animation, transitions between the View and manipulations with the child Views
        • Keeps a strong reference to the ViewModel, but knows nothing about the Model
        • Monitors the ViewModel and communicates with it using the Data Binding or referring to it directly
      • ViewModel
        • To avoid the strong relationship between the view and the ViewModel, you need to create an interface through which the view will communicate with the ViewModel. The ViewModel is the mediator between the View and the Model and Is responsible for the processing of presentation logic
        • Keeps the state of the view
        • Knows about the Model and can change its state (calling methods of appropriate classes)
        • Transforms the data from the Model into a format which is more convenient for the view
        • Validation of data which come from the view
        • Does not know about the view and can interact with the view through the data binding mechanism
      • Data binding
        • Cocoa has its own data binding
        • CocoaTouch does not have its own data binding
          • We can do with KVO, but this thing is not convenient to use and allows you to implement only unilateral binding.
        • Data binding makes it possible to implement the full potential inherent in MVVM and facilitate the development in general. So you should use some third-party libraries that provide Data Binding to CocoaTouch, or reactive programming
        • UIViewController in a MVVM is regarded as a part of View
      • How do you implement navigation?
        • The view directly performs transition to a different view. So there are two options for how to make the transition
          • The transition is initiated from a view, the ViewModel of a current scene creates the ViewModel of the next scene (if necessary it configures it by a model). Then the View creates the View of the next scene, passes it the new VIewModel, and performs the transition.
          • The transition is initiated from the ViewModel. As the ViewModel knows nothing about the View, it cannot make the transaction. In this case, a special component-Router – is required, it knows the hierarchy of the View and how to make the transition. The ViewModel can pass to the Router a VIewModel or Model of the next scene. The Router deals with everything else
      • Disadvantage
        • Mostly in Databinding mechanisms, as in certain situations, it may require significant memory resources and also is a weak spot for the Memory Leak emergence.
    • Apple MVC
      • Apple MVC on which actually the frameworks Cocoa and Cocoa Touch are built. In this pattern the Model is the same as in the classic MVC. It must be active (i.e informs about changes in this condition, usually with the help of a pattern observer)

In cocoa and cocoa touch frameworks for those purposes NSNortificationCenter and KVO can be used

  • Advantages over regular MVC
    • There is not longer a connection between the view and the model.
      • The view’s state and the processing logic of representation are in the controller
    • Diastases of Apple’s MVC
      • Controller contains some part of the View’s state and almost all the view logic
      • As the Controller also serves as a mediator between the View and the Model, it becomes a very attractive place for Application logic accommodation => the UIViewController classes become too bulky
      • Because of strong relationship between the controller and the view, they are regarded as components of the presentation layer
      • View-Logic – a logic associated with the management of widgets hierarchy, animated transitions from one scene to another, showing a dialogue, etc
      • Presentation-Logic – Logic associated with the transformation of domain model to a model that can be displayed on the view, and processing the events from the View that require manipulation of the domain model.
      • Domain-Logic: a fundamental logic that runs at the level of the Model with Model objects. Domain Logic can this be reused in another application
      • Application logic – the logic inherent in a particular application. This one is different from the Domain Logic – it can be reused, because it is specific and unique to a particular application
  • Don’t’: Do not store data directly in the UIViewController
  • Don’t: Your UIViews do almost nothing
  • Don’t: the model is a dumb data structure
  • Don’t.: your unit test covers nothing
  • GOOD Architecture:
    • Balanced distribution of responsibilities among entities with strict roles.
      • The easiest way to defeat complexity is to divide responsibility among multiple entities following the single responsibility principle
    • Testability usually comes from the first feature (and do not worry: it is easy with appropriate architecture)
    • Ease of use and low maintenance cost
      • The least code you have to use the less bugs you have to worry about

iOS Architecture Patterns:

https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

iOS architecture patterns: A guide for developers

https://thinkmobiles.com/blog/ios-architecture-patterns/