preface

MVVM is much better than MVC, and its biggest function is to slim down Controller and make logic clearer. If you are still using the MVC pattern, I suggest you start using MVVM.

Of course, many of my friends use RAC in conjunction with MVVM, and I used RAC for a while, but eventually gave up. The reason is a matter of personal habit.

The problem

Many people are also thinking about slimming down Controller:

For example, some people put all of their logic into M, which is M might have a bunch of attributes like name,sex,age, and then have a list of their own data, network requests and so on, and it would look messy.

For example, some people choose to inherit, writing many similar network requests like lists to their parent classes.

For example, some people will choose to use classification to process data.

In short, they all have their own responsibilities, such as inheritance, classification, Model, etc.

I still recommend using MVVM! Even if your project isn’t complicated!

MVVM

We use a Person module (listing the data, and editing the data for details). Take an example of how to design an MVVM architecture in detail.

Project structure Drawing:

Architectural design:

  • Model Data Model

    The data model here should always be the same as the M of traditional MVC, and its main function is to map data. JsonObj, Dic and so on are converted into objects through YYModle.

    For example, we create a Person class:

    #import < Foundation/Foundation.h > @interface Person : NSObject //id @property (nonatomic,copy) NSString *pId; // name @property (nonatomic,copy) NSString *name; @endCopy the code

    I’ll leave it at that. M layer only cares about the structure of the data.

  • ViewModel

    Viewmodels are relatively complex, do a lot of things, and more complex.

    • Network request

    • Data cache read and write

    • Validators (form parameters, return values, etc.)

    • The data processing

  • The View to layer

    The view layer only cares about two things, how the interface is built and what data is presented (not how the data is processed), so there is usually a property of the Model.

    Views generally fall into the following categories:

    • Cell (including Table and Collection)
    • View (more pure code)
    • Storyboard (simple interface, V is all there)


    I remember when I first got into iOS development, I used to use pure code, and then XIB. Later, due to the diversification of iPhone sizes, I also switched to Storyboard.

    Of course none is the best solution, a lot is a matter of personal habit, but I prefer to use SB plus some pure code hybrid mode. As for XIB, I give up.

    There are two situations when SB is used:

    • Simple TableView:

    We just need to create a separate Cell:

    PersonCell.h  
    Copy the code

    PersonCell.m

    I’m used to writing controls inside.m and exposing a Model at.h to receive the displayed values.

    The other advantage of this is that you’re also sliming down the Controller, because after you create the Cell, you only need code like this to display the data.

    cell.personM = [self.personVM.persons objectAtIndex:indexPath.row]


    • Complex View

      View is not as friendly as TableView, some complex interface, N multiple controls, in addition to SB Settings, but also to write their own Layer style.

      For example, in our Demo (the Demo is simple, the actual situation is complicated), check the edit character information:

      With SB, you will find that all controls are associated with the Controller. Some actions are very convenient, but when you style some View controls, you defeat the purpose of the Controll.

      So I prefer to create a separate View that hosts the View layer.

      Namely PersonDetailView:

      PersonDetailView.h

      In.h, we still expose only one Model to receive the displayed data

      PersonDetailView.m

      In.m, we’re going to do the same thing, we can modify the style when the View is initialized, we can assign values using setter methods, and we can handle delegate and Action for some controls

      So if I have a button action on my V layer, how do I pass it to the Controller, I usually use a delegate block to do that.


  • The Controller Controller

    After writing so much, I finally want to write C. Since I lost weight for C, how much weight did C lose?

    Let’s start with the code for the following table:

    PersonListController.m

    The total is about 50, so it feels ok. And the code is extremely readable.

    There is often more to it than this simple list, such as drop-down refresh, load more, interface statistics, navigation styles, etc. I prefer to use inheritance to slim down code.

    Note:

    In PersonDetailViewController, I put the whole PersonViewModel sent in the past, not only to a selected Person.

    According to?

    As I said just now, PersonViewModel contains most of the whole module network requests, as well as the validator, in PersonDetailViewController modified character information will be used.

    PersonDetailViewController.h

    PersonDetailViewController.m

    Obviously, there are several things to do in detail:

    1. Display the current avatar and name of the VM.
    2. Implement V proxy (modified avatar click event to get modified name)
    3. Complete the network request
    4. After the modification is complete, the list is returned to inform the list to reload data (ignored by Demo).

    Based on this architecture, we can see that the slightly more complex DetailViewController has a very clear structure, with a small amount of code and great readability.


conclusion

This article is just a primer on the basics of the MVVM framework, but more layers are needed to write a good code architecture.

When dealing with very complex business, VM can no longer meet our business needs,

We may need a Service layer to handle this.

For network requests, we need to encapsulate a network layer.

In short, we still hope that according to the characteristics of different projects, do a good job in accordance with local conditions.


Note:

Later I will write separately about network request, database FMDB encapsulation and so on. I hope my article can help you