IOS MVC-based Project refactoring summary

The debate about MVC

There's been a lot of debate about MVC, and my point is that MVC itself is no problem for most of the scenarios in iOS development, and you think that the MVC problem must be something you understand (the senior architect automatically ignores this article ).

In the process of reading a large number of documents on the Internet, where the level of good and bad (the most common is the MVC renamed as MVVM), of course, there are many valuable references, at the end of the text will be listed, for reference.

MVC and Mvpcocoa versions of MVC in iOS

According to the official website, the MVC in cocoa is this:

• Model Objects encapsulate Data and Basic behaviors

• View Objects Present information to the User

• Controller Objects Tie The Model to the View

The difference between C and P

Through the search engine, found that in fact, two kinds of MVP:

1. Passive View

2. Supervising Controller

Absolute part of the online talk about the MVP article is actually passive view, here put on a passive view:

Does it look like MVC at first glance? I have been confused until StackOverflow see this answer:

Mvp:the view is in charge. The view, the most cases, and creates its presenter. The presenter would interact with the model and manipulate, the view through an interface. The view would sometimes interact with the presenter, usually through some interface. This comes down to implementation; Do you want the "view to" methods on the presenter or does you want the view to has events the presenter listens to? It Boils this:the View knows about the presenter. The view delegates to the presenter.

Mvc:the Controller is in charge. The controller is created or accessed based on some event/request. The controller then creates the appropriate view and interacts with the model to further configure the view. It boils down To:the controller creates and manages the view; The view is slave to the controller. The view does not know about the controller.

In short, the MVP is view-driven, the view layer holds a reference to the corresponding presenter, and the interaction event on the view first invokes the interface provided by the presenter, and then presenter invokes the method provided by the model to obtain the data, Finally, presenter the data that was obtained to show on the view.

MVC is driven by the controller, which holds the view and responds to the interactive events on the view, obtains the feedback data according to the interaction call different model method, and then passes the data to the view display.

My understanding is that MVP is the user's point of view: What is seen as VIEW.MVC is the programmer's point of view: I control everyone.

Understanding the difference between MVC and MVP is the question of whether theUiviewcontroller belongs to the C (P) or V-level? The following will be a detailed analysis of these two points of view.

Point one: Uiviewcontroller's Attribution--->view

If Uiviewcontroller is treated as a V-layer, that is, the MVP in the above passive view, then Uiviewcontroller will only be responsible for the view layout-related logic, does not involve any interaction with the model layer!!

No interaction with the model layer is involved!!

No interaction with the model layer is involved!!

All business logic interactions are done through the call between presenter and model held by Uiviewcontroller.

Point two: Uiviewcontroller's Attribution--->controller

If you think of Uiviewcontroller as a C-layer, from the MVC design concept, the C layer will not be responsible for the layout and presentation logic of the specific view, but because of the special design of Uiviewcontroller in iOS, Cause many developers directly in the Uiviewcontroller contains a lot of specific layout-related code, and more frightening is not only the view of the initialization, including network requests and specific business processing is also included in the Uiviewcontroller, which is perhaps someone called MVC to : The reason for Massiveviewcontroller.

The differences between Model,datainfo and the controversial model and datainfo of the fat-thin model

The MVC architecture idea prefers that model is a layer rather than an object (a bean in Java or Android).

So here's the datainfo I define it as a DTO (data Transfer objec), more simply, a data structure, and a student structure that we write when we learn C in school is basically a meaning.

My understanding is that model is used to handle business logic and can be seen as a combination of the BLL (bussiness logic Layer) and the Dal (Data Access layer) in a traditional three-tier architecture, and is responsible for all the specific business. For example, for an app that contains secure authentication , you may need a authmodel to take care of all the authentication logic and local persistence of the authentication information. In this way, the controller only needs to invoke the interface provided by Authmodel to complete the corresponding security authentication function, clear responsibility.

Some of the methods in model output DTOs, which are used to update the view. For example, Usermodel will query the user information and then convert the user information returned by the server into a local userinfo, and pass the userinfo to the view for display.

As a result of the industry's controversy over the fat-thin model, I am more aware of the controversy over whether Datainfo needs to provide extended functionality related to the business.

Examples of business scenarios

For example, a business scenario, a user information view needs to show the user's gender, generally speaking, the server will only include a sex field in the returned user information (0 for women, 1 for men), need to use the IF statement to determine and then output a different gender text or pictures.

In personal terms, many developers convert the user information returned by the server into a local userinfo DTO, then pass the DTO to the view that needs to be displayed, and then make the output judgment in view.

Of course, developers may use some of the most popular dictionaries to model frameworks (yymodel,mjextension, etc.), or they can use the configuration interfaces provided by these frameworks to transform this output logic at the time of conversion, or directly in Uerinfo The Sex property of the Getter method is converted after the output.

In any case, as long as these transformations are done at the datainfo level, the business logic has penetrated the definition of dtos.

A solution to the idea

However, this scenario is almost inevitable, how to solve it? Misunderstood MVC and deified MVVM put forward a solution to the idea of using MVVM, which is the process of passing data Viewcontroller to View, which is abstracted into structure ViewModel Process. After this abstraction, the View only accepts ViewModel, and the Controller only needs to pass ViewModel such a line of code. In addition to the process of constructing ViewModel, we can move to another class.

In my opinion, this viewmodel layer is just a separate refinement of the datainfo extension above. This completely isolates the view layer completely from the business logic.

This project reconstruction step based on MVC thinking about the problem to be solved

Back to the question of project refactoring, I think the first thing to think about is the project refactoring:

2. How is the project hierarchy divided?

4. What are the big business scenarios?

6. Classify Uiviewcontroller as a view or controller?

8. Who will be responsible for the network request, model or controller?

10. How does the controller pass the data to the view to display when the data is obtained from the model? Pass through the view hierarchy? Do I need to use ViewModel?

12. How is the model's life cycle controlled? (The division of the global model and the private model)

14. How do you pass user interaction when the view hierarchy is getting deeper? (No doubt nsnotification)

Division of Uiviewcontroller

This refactoring still classifies Uiviewcontroller as C layer, but in order to leave Uiviewcontroller thoroughly and UIView, naming us to use Xxxcontroller directly, We have designed a corresponding UIView object named Xxxcontainerview for each xxxcontroller, and all the view layouts will be done in this xxxcontainerview.

Project directory Structure

The reconstructed project directory structure is as follows:

Level table of Contents	Sub-directories	Catalogue Description
Macro		Store some of the macro definitions you need during the development process
Category		A classification that does not involve business and is used to assist development
Tools	Different types of business tools	Store processing classes that involve lightweight business, such as outputting different strings based on different business formats
Views	Different Business Module page names	Store the V under different business module pages
Controllers	Different Business Module page names	Store the C on the different business modules page
ViewModels	Different data module names	The data translation layer, which translates datainfo data into data that can be displayed directly in view, but is not forced to use in this refactoring due to time factors
Model	Publicmodel	Common global model, such as user information Usermodel
	Moudlemodel	Private model used by a single module, only responsible for private business
Services	Different service	Provides the underlying services, such as Httpservice,securityservice

Business Scenario Division

As a result of prior to the development of progress, did not do a specific function split. This refactoring was preceded by the use of startuml to draw a UML diagram in the main scenario, including class diagrams, time series diagrams, and flowcharts.

It is strongly recommended that this step be completed before the new project is formally encoded, and that the UML review will be conducted by the front and rear technical leaders. All the property of the business model involved and the public method, all attributes of the Datainfo class, Even all controllers will be produced in the process of drawing UML. Of course, it can take a long time to draw a UML diagram in all scenarios, usually by drawing out the main interaction scenarios.

Network requests

Basically all of the network requests on the mobile phone are tied to the business, which is obviously more appropriate in the model. As for the callback after the request is done, it looks like a personal habit, delegate or block is feasible.

Subsequent

Due to time reasons, and did not write the specific sample code, and then for a sample scenario, I understand the various MV (X) mode of reference code, look forward to writing and peer discussion.

MVVM extension

To put an MVVM:

Does it look like an MVP? Just a two-way binding of view and ViewModel, it is emphasized here that RAC does not necessarily log on to MVVM,MVVM and does not necessarily use RAC.

Resources

• Misunderstood MVC and the deified MVVM

• OBJC China-MVVM Introduction

• iOS App architecture Talk series

• IOS Schema mode-decrypt MVC,MVP,MVVM and Viper architecture

• Model-view-controller

IOS MVC-based Project refactoring summary