IOS project architecture

Time:2022-5-22

1、 Architecture layering:

Three tier architecture:

  • Application layer / interface layer
  • Business layer
  • Data layer

Four tier architecture:

  • Application layer / interface layer
  • Business layer
  • network layer
  • Local data layer

understand:
The application layer is used to manage the loading interface, such as tableview.
The business layer is used to handle project business, such as login, loading list data, etc. the created Manager / service class belongs to the business layer.
The data layer can be divided into network layer and local data layer, which are respectively used to initiate network requests, access the database locally and provide data to the business layer.

For example, a news app:

IOS project architecture

image.png

2、 MVP / MVC:

These three architectures belong to the architecture of application layer

1. MVC (Apple version):

model —view —controller

IOS project architecture

image.png
IOS project architecture

image.png

Understanding: uitableview is a typical Apple MVC Architecture: the controller loads the tableview, obtains the model data, and fills the content of the model into the view in the controller, such as cell nametext = model. name;
Cell and model are not interdependent.

Advantages: model and view can be reused and used separately (uitableview is a typical Apple MVC)
Disadvantages: the controller code is too bloated

2. MVC (variant version):

model —view —controller

IOS project architecture

image.png

Understanding: it is also our commonly used view. Bind a model, cell Userinfo = userinfomodel. In this way, the assignment operation of the view attribute is placed inside the view, and some properties of the view can be hidden.

Advantages: the controller is slimmed down and the internal details of the view are encapsulated. The outside world does not know the specific implementation of the view
Disadvantages: view depends on Model

3.MVP:

model —view —presenter

IOS project architecture

image.png

Understanding: the presenter completes the binding of the view model internally, and the view and model do not depend on each other. The controller only needs to create a management presenter, which makes the controller more streamlined.

4.MVVM

model — view — view-model

IOS project architecture

image.png
IOS project architecture

image.png

MVVM framework is evolved on the basis of MVC. The problem that MVVM wants to solve is to reduce the tasks of controller as much as possible.

  • Model: the abstraction of the actual object to be manipulated in the program
  • View (viewcontroller): view in MVVM is no longer a subclass of uiview, but a subclass of uiviewcontroller. The view here is actually the controller that handles the logical part of the presentation view in MVC. Therefore, it still has various uiview properties and various methods of viewcontroller’s declaration cycle. However, the controller here is no longer responsible for data requests and processing logic, so it is no longer bloated.
  • ViewModel: in MVVM, ViewModel replaces the controller in MVC and becomes the coordinator. The ViewModel is held by view (viewcontroller) and the model is held at the same time. The data request and processing logic are placed in the ViewModel, and the view (viewcontroller) becomes thinner.

Understanding: the ViewModel is similar to the presenter. The controller only needs to create and manage the ViewModel, which makes the controller more streamlined.
The core difference between holding ViewModel and holding ViewModel,。
Thus, the view can monitor the change of ViewModel property and update the view.
Therefore, it is generally used in combination with MVVM + RAC / KVO

viewcontroller.m
//Create and manage viewmodels
- (void)viewDidLoad {
    [super viewDidLoad];
    self.viewModel = [[AppViewModel alloc] initWithController:self];
}
ViewModel.m
//ViewModel creates and manages views and models, and handles click events of views
- (instancetype)initWithController:(UIViewController *)controller
{
    if (self = [super init]) {
        self.controller = controller;
        
        //Create view
        AppView *appView = [[AppView alloc] init];
        appView.frame = CGRectMake(100, 100, 100, 150);
        appView.delegate = self;
        //Viewviewmodel
        appView.viewModel = self;
        [controller.view addSubview:appView];
        
        //Load model data
        App *app = [[App alloc] init];
        app.name = @"QQ";
        app.image = @"QQ";
        
        //Set data
        self.name = app.name;
        self.image = app.image;
    }
    return self;
}

#pragma mark - AppViewDelegate
- (void)appViewDidClick:(AppView *)appView
{
    Nslog (@ "ViewModel listens to appview clicks");
}
view.m
//View owns the ViewModel and listens for changes in ViewModel properties
- (void)setViewModel:(AppViewModel *)viewModel
{
    _viewModel = viewModel;
    
    __weak typeof(self) waekSelf = self;
    [self.KVOController observe:viewModel keyPath:@"name" options:NSKeyValueObservingOptionNew block:^(id  _Nullable observer, id  _Nonnull object, NSDictionary<NSKeyValueChangeKey,id> * _Nonnull change) {
        waekSelf.nameLabel.text = change[NSKeyValueChangeNewKey];
    }];
    
    [self.KVOController observe:viewModel keyPath:@"image" options:NSKeyValueObservingOptionNew block:^(id  _Nullable observer, id  _Nonnull object, NSDictionary<NSKeyValueChangeKey,id> * _Nonnull change) {
        waekSelf.iconView.image = [UIImage imageNamed:change[NSKeyValueChangeNewKey]];
    }];
    
}