1. The MVC pattern

  • View: Responsible for displaying the View
  • Model: Responsible for data storage (network requests)
  • Controller:
    • For views: Responsible for responding to interactions and refreshing views
    • For Model: responsible for initiating requests and receiving data

2. The MVP pattern

You might find that MVP is not much different from MVC in terms of flow, but what does MVP mean?

We’ve been talking about MVC/MVP scenarios for a single business, but let’s look at multi-business scenarios

3. MVC/MVP in multi-service scenarios

  • MVC of multi-business composition

  • MVP of the multi-business portfolio

As we can see, when there are more business modules in a page, the Controller needs to write the logic processing and data of each business together, so that the code amount of the Controller will increase exponentially, which is the reason for the fat VC*

For MVP, each module has a Persenter to handle its business, each module is isolated (ideally), and our ViewController is only responsible for scheduling views or Presenters during their life cycle

4. MVP pros and cons

  • advantage
  1. The business logic of each module is separated and clearer
  2. Modules are highly reusable and can be taken away and used
  3. Easy unit testing
  4. The idea of protocol-oriented programming, which makes code more robust through protocol conventions
  • disadvantage
  1. The number of documents, the number of agreements will increase
  2. Module division needs clear thinking, if the division is not reasonable will get half the result with twice the effort
  3. The handling of relationships between modules becomes complicated